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Die wissenschaftliche Tagung, "Berliner Informatik-Tage 19R7“, 
die vom 28. Juni bis zum 2, Juli 1982 an der Humboldt-Univer- 
sität zu Berlin stattfand, war folgenden thematischen Schwer- 
punkten gewidmet: 


Organisation und Technologie der Softwareproduktion, 
Anwendung und Nachnutzung von Softwareprodukten, 
Datenverwaltungssysteme sowie 

Software zur Automatisierung der Rechenbetriebs. 


Es wurden in Plenarvorträgen und in vier Sektionen Ergebnisse 
von Forschungs- und Entwicklungsarbeiten zu diesen Themenkom- 
plexen von Referenten aus verschiedenen Bereichen der Volks- 
wirtschaft, aus Akademieeinrichtungen und Hochschulen vorge- 
stellt und in den Sektionen kritisch diskutiert. 


Im vorliegenden Tagungsbericht werden die Manuskripte der mei- 
sten Beiträge veröffentlicht. Einige Referenten baten jedoch 
darum, von einer Veröffentlichung an dieser Stelle abzusehen, 

da Reiträge aus ihrer Feder zum gleichen Thema inzwischen in 
Fachzeitschriften erschienen seien. Wir haben diesem !Yunsch ent-. 
sprochen. Bedauerlicherweise konnten einige andereReferenten 
ihr Manuskript nicht rechtzeitig bereitstellen - auf ihren 
Beitrag mußte deshalb in diesem Bericht verzichtet werden, 

Alle, eingereichten Manuskripte werden ungekürzt wiedergegeben, 


Für ihren Anteil an der Pesteltung des vorliegenden Yaterials 
danken wir allen Autoren - für ihr aktives Mitwirken an der 
"bit'82“ geht unser Dank an elle Referenten und Liskussions- 


redner. 
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Zum Zusammenhan;, von Orzanisation und DV-Projektierung 


1. Aufgaben, ilolle und wissenschaftliche Grundlagen 


der Orzanisation 


a L—— se un? 
1.1. Aufgaben und Kolle der Organisntion bei der soziali- 
stischen kationalisierung 


Unter der Tätigkeit der Organisation bzw. des Organisierens 
verstehe ich in Übereinstimmung mit den meisten Autoren die 
bewußte Herstellung eines Zustandes der Ordnung /1/, die 
Aufgaben der Strukturierung und Regelung eines sozialöko- 
nomischen Systens zur Erreichung der Betriebsziele /2//5//21/. 


Moderne Auffassungen zur Organisation beziehen stets den 
“Aspekt des zielorientierten Entscheidens im Sinne "Konzi- 
pierender Entscheidungen" ein, wobei " „.. eine Handlungs- 
‚kette vorbereitet wird, deren Handlungsakte zur Erreichung 
“der Zielstellung führen „.." /40/ /. = 
‘Die von der Erfüllung vorgegebener Ziele ausgehenden organi- 
satorischen Entscheidungen haben primär die zweckmäßige 
Struktur und den Ablauf von Handlungsfolgen zum Gegenstand, 
woraus sich die zwei bekannten, konventionellen Hauptaspekte 
des Gegenstandes der Organisation ergeben, nämlich die Ab- 
lauf- und Strukturorganisation /19/ /21/. 


Von dem Autorenkollektiv "Informatik und Automatisierung" 
wird der technologische Aspekt der Entscheidung" „.. auf den 
Inhalt der einzelnen Handlungsakte", der organisatorische 
dagegen auf "das geeignete Zusammenwirken dieser Handlungs- 
akte" (S. 44) bezogen /21/. Daraus kann die Bedeutung der 
Technologie und der Organisation in ihrem Zusammenwirken 
abgeleitet werden. Ich persönlich folgere daraus nicht nur 
eine gewisse strategische Rolle der Organisation zur Vorbe- 
reitung und Durchsetzung einer rationellen Technologie, 
‚sondern verbinde nit dem Wort Organisation stärker den 
Aspekt der Koordination von einzelnen und kollektiv tätigen 
Wenschen, Noch stärker als bei der Technologie ist bei der 


Organisation die Information Gegenstand, Mittel und Resultat 
der Organisationsarbeit, der stoffliche und energetische 
Aspekt eines Prozesses tritt bei ihr gegenüber der infor- 
nationellen Verknlipfung menschlicher und maschineller 
Handlungen bzw. Operationen zurück, Damit wird bereits ein 
Unterschied der Organisation menschlicher Tätigkeiten ge- 
genüber der Technologie deutlich: 

die Technologie kann sich primär mit formalisierbaren Ope- 
rationen beschäftigen /41/, die Organisation muß primär den 
Nenschen mit seinen individuellen Fähigkeiten einbeziehen. 
Sie ist damit von der Qualifikation und Motivation der 
Menschen und spezifischen menschlichen Eigenschaften und 
damit stark von gesellschaftswissenschaftlichen Erkenntnis- 
sen abhängig, hat enge Beziehungen zur Sozialogie, Arbeits- 
psychologie und -physiologie und stellt an diese neue For- 
derungen. j 
Organisation als wissenschaftliche Disziplin läßt sich damit 
primär den Wirtschaftswissenschaften zuordnen, trotz eines 
tendentiell stärkeren Einflusses der Informations- bzw. Or- 
ganisationstechnik. Trotz oder gerade wegen der gegenüber 
der Technologie starken Abhängigkeit vom komplizierten Sub- 
jekt und wichtigstem Objekt der Organisation in Form der 
Arbeitskraft, stimme ich dem Autorenkollektiv unter Leitung 
von Fuchs-Kittowski zu, wenn es die Notwendigkeit betont, 
daß die Rationalisierung insgesamt auf wissenschaftlich 
fundierten Methoden aufbauen muß, Daraus folgt die Notwen- 
digkeit, auch die Organisation wissenschatlich zu betreiben 
und ihr Verhältnis zu anderen Disziplinen zu untersuchen. 


1.2. wissenschaftliche Grundlagen der Organisationsarbeit 
und deren Bedeutung für die Informationsverarbeitung 


Folgende Übersicht zeigt einige wichtige Ansätze organisa- 
tionswissenschaftlicher Theorien /41/, die auch für die 
EDV-Organisation von Bedeutung sind: 


(nach Tschirschwitz) 


1. Klassisches Waschinennodell der Organisation bzw. 
Taylorismus 


2. Human Relations Approach (Organisations-Entwicklung) 


30 Modell der kybernetischen Naschine bzw. Automat als 
Modell der Organisation 


4.. Modell des soziotechnischen Systens bzw. allgemeiner 
systemtheoretischer Ansatz 


5. Organisation und kybernetisches Systen als Ausdruck 
der Subjekt - Objekt -— Dialektik (Information und Wert, 
Aktion und Punktion, Kommunikation und Information, 
Rationalität und Humanismus im dialektischen Wechsel- 
verhältnis von Unterschied und Gemeinsamkeit), 


Die skizzierte Entwicklung geht aus vom Taylorismus. und 
mündet in modernen Informatik-Theorien. 


Das klassische Maschinenmodell der Organisation bzw. der 
Taylorismus reduzierte den Menschen primär hinsichtlich 


seiner Fähigkeiten zur Durchführung von Routinetätigkeiten 
/24/ /41/ im Produktionsprozeß und leistete primär einen 
Beitrag zu Zeit- und Nethodenstudien., 


Viele EDV-Organisatoren werden bestätigen, daß das Modell 
der kybernetischen Maschine, der abstrakte Automst, oder 
Regelkreisvorstellungen für uns auch heute noch wichtige 
Denkmodelle sind /41/. 


(Vgl. Vortrag von Fuchs-Kittowski) 
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Das soziotechnische System weist auch den EDV-Organisator 
darauf hin, daß auch bei aus seiner Sicht zweckmäßiger Lö- 
sung der technologischen, strukturellen und Steuerungsfragen 
große Auswirkungen aus dem psycho-sozialen Bereich kommen 
können, die Automatisierungsvorhaben stark bei (flussen 
/a1/ /2a/ 128/ 

Aus der Literatur über Nensch-Laschine=-Kommunikationssysteme 
wird deutlich, daß die IV-Spezialisten schon über die zu- 
mutbare bzw. vertretbare Wartezeit am Bildschirm höchst 
divergierende Auffassungen vertreten. Alle genannten Ansät-, 
ze heben bestimmte Aspekte hervor und haben auch für die 
EDV-Organisation m. E, noch methodologische Bedeutung. 


Die an der Sektion Wissenschaftstheorie und Wissenschafts- 
organisation der Humboldt-Universität vertretenen Auffas- 
sungen, wie sie im 5. Ansatz angedeutet sind, führen m. E, 

zu einem besseren Verständnis von Organisationsgrundtypen 
als. Gegenstand und Resultat der Automatisierung /41/ /2/, 
wobei physionomische (nicht organisierte), Funktions- (organi- 
sierte), von Aktionssystemen (organisierenden) unterschieden 
werden. 


"Organisationstechnologien enthalten die "... organisatori- 
schen Anforderungen an die Gestaltung von Aktionssystemen 
auf der Orgware-Ebene ..." /41/, deren Inhalt Sinngebung 

und Bewertung usa. von Funktionssystemleistungen in Aktions- 
systemen ist. 


In diesem Sinne wird vom genannten Autorenkollektiv /2/ die 
Informatik als theoretische Grundlagenwissenschaft für die 
Organisation und die Informationsverarbeitung verstanden, 
Hierzu ergeben sich trotz meiner Zustimmung zu prinzipiel- 
len Aussagen aus meiner Sicht eine Reihe von Problemen, Fra- 
gen und anderen Auffassungen, ‚von denen ich hier nur einige 
nennen möchte: 


1. 


3° 
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Der sicher von Anliegen her begrlindet weitgehend philoso- 
phisch-soziologisch orientierte Begriffsapparat und das 
hohe Abstraktionsnivcau der Aussagen führen nach meiner 
Auffassung zu einer gewissen Verständigungsbarriere be- 
sonders zu Vertretern einzelner technisch-technologi- 
scher Teildisziplinen der Informationsverarbeitung und 
gegenüber vielen Praktikern, 


Die bisherigen meist deduktiven, abstrakten Untersuchungen 
sollten meiner Ansicht nach durch anwenäungsbezogene metho- 


‘isch bzw. .technologisch orientierte Untersuchungen, z.B. 


zur Reduktion von Aktionssystemen, zur- Organisations- 
technologie und entsprechende Erprobungen ergänzt werden, 


Wenn diese Aussagen als Anleitung zum Handeln fungieren 
sollen, ist eine Vermittlung dieser Untersuchungsergeb- 
nisse gegenüber möglichst allen wissenschaftlich tätigen 
IV- und Orgspezialisten in Form entsprechender Seminare 
zweckmäßig, so daß es über die anwendungsorientierten 
Teildisziplinen zur Praxisanwendung kommt, 

Die angewandte IV wird sich auch künftig, trotz des direk- 
ten. Bezuges und der Einordnung in Aktionssysteme primär 
nur mit der Schnittstelle zur semantischen Informations- 
verarbeitung und trotz ihres Applikationscharakters mit 
syntaktischer Informationsverarbeitung für definierte 
Nutzeraufgaben beschäftigen. 


Um Vorschläge zur Zusammenarbeit von Organisatoren und 
IV-Spezialisten abzuleiten, ist es notwendig, einige 
Aussagen zur Spezialisierung von Organisatoren zu for- 
nulieren, worauf ich im folgenden eingehen will. 


Tabclle 3 


Vorschlag für die berufliche Spezialisicrung von Urgzanisatoren 


d deren Aus- und 


Neiterbildunz 


un ee ee 


sol, 


Grsani 
Spezial-VDi 


Ip 


_ 
[el 
52 


lin 


wirtschafts- 


organisation 


Leitunss- 
orsanisation 


Produlstionsorgani- 
sation 


Berceichs- 
organisation 


Om 


Vervalsungs 


organisation. 


WAU 


liochschulausbildz. 
einschl. 5pezinli- 
sierg.u.Vertiefung 
Wirtschaftsorganisator " 
Wertiefunssrichtung In 


d.Fachricht. 
‚ Volkswirtschaft) 


Leitungsorganisator 

Wertlef.-richtung bzw. 
primäres Ziel ä.Fach- 
richtung. 


Leitungs 
wissenschä’t) . 


ator 

5-, Verwaltungs 
orsanisator, 
Arbeitswissenschaftle 
issenschaftsorganis. 
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AzuSESZißsıS, 

Ze zur 


2) 


-Torschunssökonanie 
-Ünlasentechni!: 
-Volkswirt 


Ion 


Hochschulgrundstudiun: 
“irtschaftswissenschsfte 
Spezialisierung: 

Verwaltungsorganisation 


arbeiiswi 
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Scls 


Postgraduale 
Spezialisierung 


f..Kkonbinate 
f, Staatsapparat 


f.Wirtschaft u. 
Handel 

f. Staatsapparat,- 
Gesundheitswesen 
u. sonst. 


postgraduales 
Studium 


primär 
fachbereichs- 
bezogen 


primär 
orsenisations- 
bezogen 


Vertiefung 
Org.-technik 
liethoden d. Ver- 
waltungsorgan. 
WO 
Leitungssorzanis; 
Verwaitungsorss. 
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Tabelle 3 fTortsetzg. 


Organisation 
Spezial-Disziplin 


Infornations- bzw, 
EDV-Organisation 


Wissenschafts- 
organisator 


13 


Hochschulausbildg. 
einschl. Speziali- 
sierg.u.Vertiefung 


N 


Wirtschaftswissenschaften 
Infornationsverarbeitung 


(ASU-Kadergruppe IVa mit 
ca. 25% Inforn.-verarb.- 
Anteil) "Angewandte IV" 
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organisation 
Anwendungsge- 
blet 


‚Inform.-verarb. 
‚Anwendungsgebiet 
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.Leitungsorgan. 
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.Leit.-orgaris. 
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«WAO 

‚TEVO 


postgradual 
Spezialisierung 
auf 1 Fachgebiet 


Spezialisierung 
auf Wiss.-Org.? 
Inforn.-Verarb. 


Spezialisierung 
auf Wiss.-ürg./ 
Inforn.-Verarb. 
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1.3. Probleme der Spezialisierung von Organisatoren 


Die Spezialisierung von Organisatoren ist eine Vorausset- 
zung für die detaillierte Beschäftigung mit Fragen der je- 
weiligen Anwendungsdisziplin, um eine ausreichende Detail- 
liertheit in der Auseinandersetzung mit dem Arbeitsgegen- 
stand zu erreichen und um detaillierte praktische Erfah- 
rungen im Berufsleben kumulieren und schöpferisch anwenden 
zu können, Zu dieser Frage gibt es weder in der Literatur, 
noch in der Praxis einen einheitlichen Standpunkt, Hierzu 
will ich meine persönliche Meinung aus der Sicht organisa- 
torischer Überlegungen zur DV-Projektierung darlegen. 
Dabei stimne ich u, a. mit dem Autorenkollektiv des Leit- 
fadens zur Organisationsprojektierung /3/ nur teilweise 
bei der Formulierung unterschiedlicher Gegenstandsbereiche 
der Organisation als Grundlage der disziplinären Speziali- 
sierung und Arbeitsteilung überein, wie Tabelle 3 zeigt. 


Die Organisationsprojektierung sollte meiner Auffassung 
nach nicht als eine berufliche Spezialisierungsrichtung 
aufgefaßt werden, sondern als eine vorhabenbezogene kom- 
plexe Organisationsaufgabe, bei der eine umfassende organi- 
satorische Rationalisierung für ein definiertes Investob- 
jekt, eine definierte Struktureinheit, einen definierten 
Prozeß interdisziplinär von unterschiedlichen Organisa- 
tionsspezialisten und anderen Fachleuten gelöst wird. 


Die klare’ Abgrenzung eines Organisatoren-Profils, das ne- 
ben der dringend erforderlichen und von außen durchschauba- 
ren Spezialisierung, gleichzeitig eine bestimmte Bildungs- 
ökonomie und die postgraduale Weiterbildung einbezieht, ist 
ms E. eine primäre Voraussetzung für die rationelle Organi- 
.sation interdisziplinärer Arbeit, wie sie u. a; die Gestal- 
tung autonatisierter IVS darstellt. 
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2. DV-Projektierung als Mittel und Gegenstand der Organi- 
sation in Prozeß _der Rationalisierung 


2.1. DV-Projektierung als interdisziplinäre und organi- 
satorische Tätigkeit (Mittel der Organisation) 


Gehen wir von der in der Rahmenordnung der DV-Projektierung 
enthaltenen Begriffsdefinition aus, denn versteht man unter ' 
DV-Projektierung "die Arbeiten zur Bereitstellung der DV-Pro- 
jekte „.." und unter diesen ",.. alle Projektunterlagen, die 
für die problembezogene Nutzung der DV-Technik erforderlich 
sind." Bekanntlich sind innerhalb der Einsatzvorbereitung, 
außerhalb der DV-Projektierung, einige Aufgaben, wie die 
Schaffung der personellen, technischen und organisatorischen 
Voraussetzungen, die primär als organisatorische Tätigkeiten 
angesehen werden müssen /37/. 
Geht man von der Gliederung des Projektierungsprozesses nach 
den je DV-Projekt und Stufe erforderlichen Projektierungsaus- 
sagen aus, wie sie in der mit SCHNEIDER gemeinsam verfaßten: 
Broschüre /37/ enthalten sind, so ergibt sich, daß zahlreiche 
Projektaussagen überwiegend bzw, teilwsise organisatorischen . 
Charakter aufweisen. Nur einige Projektaussagen, die primär 
die Implementierung betreffen, haben keinen bzw. kaum or- 
ganisatorischen Charakter. 


Insgesant kann man davon ausgehen, daß einige Projektierungs- 
stufen, nämlich Ei, E2, E5, E6 als überwiegend organisato- 
rische Tätigkeiten aufzufassen sind, 

Damit gilt die These, daß DV-Projektierung stets Organi- 
sationsarbeit darstellt, 
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2.2. DV-Projektierung als Objekt der Organisation 
DV-Projektierung stellt nicht nur selbst Organisationsarbeit 
dar, sondern ist auch gleichzeitig Objekt der Organisation 
/33/: sie wird organisiert. Typische diesbezügliche betrieb- 


liche Organisationsaufgaben sind u, a.: 


1. Abgrenzung der Aufgaben der DV-Projektanten von denen 
der Fachbereiche 

2. Ablauforganisation der DV-Projektierung 

3. Unterstellung, Aufbau- und Themengruppenorganisation 

4. Regelung der Testarbeiten, Bibliotheksführung, der Doku- 
mentation, der Anwendung von Projektierungsmethoden, der 
Verteidigung, der Nachnutzung von Software usw.e- 


Die Regelungen der Prozeßorganisation für die DV-Projektie- 
rung sind sehr fachspezifisch und haben aufgrund weitgehend 
einheitlicher Arbeitsmittel, nämlich der EDVA, in vielen 
Betrieben große Gemeinsamkeiten. Dies bewirkt, daß auch 
spezielle Orgware, das Know how zur Organisation der DV-Pro- 
jektierung nicht nur in Form unterstützender Software nach- 
nutzbar wird /33/. Damit haben auch wissenschaftliche Unter- 
suchen zur Organisation der DV-Projektiering einen hohen 
Stellenwert, Bekannt ist allgemein, daß die Mehrfachnutzung 
von Produkten geistiger Arbeit, also auch von Projektierungs- 
ergebnissen, zum Hauptkettenglied der Rationalisierung wird. 
/33/ /30/ 

Daraus leitet sich eine besondere Rolle der Organisation im 
Rahmen einer Strategie zur Rationalisierung der DV-Projek- 
tierung ab, die die über- und zwischenbetriebliche Organi- 
sation einschließt. /30/ /33/ 
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2.3. Zur Rolle der Organisation im Rahmen einer Strategie 
der DV-Projektierung 


Nach seit 1978 vorliegenden Untersuchungen kann man von 
folgenden Hauptwegen der Intensivierung der DV-Projektierung 
ausgehen /33/: 


1. Methoden, Technologien, Projektierungshilfsmittel (PH) 
einschließlich universeller Anwendungs-, Hilfs- und 
Standardprogramnme 

2. mehrfach nutzbare Gestaltung von DV-Lösungen 

2.1. Einheitsprojekte 


2.2. Teilweise variable Einheitsprojekte für einen definier- 
ten, bekannten Nutzerkreis 


2.3. variable DV-Lösungen 


3. Gesellschaftliche Organisation 

3.1. Zentralprojektierung 

3.2. Zentr. org, arbeitsteil. (koop.) DV-Projektierung 
3.3. koop. org. arbeitsteil. DV-Projektierung 


3.4. Konzentration der Kräfte und Mittel in den Formen: 
Zentralisation / Kooperation 


4. Verbesserung der Arbeits- und Leitungsorganisation 
für Prozesse der -DV-Projektierung 


Daraus. wird ersichtlich, daß die Hauptwege 

- gesellschaftliche Organisation der DV-Projektierung nit 
Konzentration, Kooperation und Spezialisierung, 

- betriebliche Leitungs- und Arbeitsorganisation 

als Hauptwege einer Rationalisierungsstrategie angesehen 

werden müssen, 

zur wissenschaftlichen Untersetzung. einer solchen Rationa- 

lisierungsstrategie gilt es jedoch, auch neue wissenschaft- 

liche Fragestellungen zur Technologie der DV-Projektierung 

unter Vereinheitlichungsaspekten zu lösen, wobei ich hier 

nur einige Gedanken zu Vereinheitlichungsfragen und zur 

gesellschaftlichen Organisation darlegen kann. 
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2.4. Zum Zusammenhang von betrieblichen Reproduktionsbedin- 
gungen, Leitungsorganisation, Leitungsinformations- 
system und Rationalisierung der DV-Projektierung 


Einleuchtend erscheint, daß das Phänomen Mehrfachnutzung 
primär von 2 Faktoren abhängig ist /33/: 


1. von bestinmten Eigenschaften der projektierten und mehr- 
fach zu nutzenden DV-Lösung, 


2. von den konkreten Anwendungsbedingungen einer DV-Lösung. 


Dabei ist trivial, daß bei einheitlichen Anwendungsbedin- 
gungen, wenn man darunter sowohl die inhaltliche Seite als 
auch die technischen und organisatorischen Bedingungen ver- 
steht, einheitliche DV-Lüsungen angewandt werden können und 
damit die Mehrfachnutzung ihr Maximum erreichen kann /33/. 
Die Grenze einer solchen maximalen Nachnutzung für problen- 
bezogene DV-Lösungen liegt im Leitungsbereich in den soge- 
nannten "betrieblichen Reproduktionsbedingungen", worunter 
man nach TRAGSDORF /39/ volkswirtschaftliche, wirtschafts- 
organisatorische, technologische und personelle Bedingungen 
versteht. Den für die Gestaltung eines Leitungsinformatlons- 
systems von TRAGSDORF dargestellten Wirkungszusamnenhang 


zeigt folgende Abbildung /39/: 

bedingungen 

Leitungsorgani- 
sation 


Leitungsinformation einschließlich 
EDV-Anwendung 
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Diese Darstellung charakterisiert die bestehenden prinzi- 
piellen Abhängigkeiten eines betrieblichen Informations- 
systems m. E,. unvollständig und damit zu einseitig, wie 
anhand der folgenden Folie gezeigt werden soll /33/: 


Über- bzw. zwischenbe- 
triebliche Informationen 
bzw. Informationsanfor- 
derungen 


etriebliche 
Reproduktionsbedingungen 


etriebliche Leitungs- 
aufgaben bzw. -funktionen Leitungsinformations- 


system einschl, DV-Syste 


Technische u. projektie- 
rungstechnische, techno-=- 
logische, organisato- 
rische Faktoren der 
DV-Projektierung u. An- 
wendung 


betriebliche. 
Leitungsorganisation 


Die zuletzt dargestellten Zusammenhänge zeigen m. E. die 
richtige Einordnung eines betrieblichen Informatlonssystens 
als Verbindungsglied bzw, Kommunikationsmittel zwischen den 
genannten Einflußfaktoren, da alle Leitungsbeziehungen aus- 
schließlich Informationsbeziehungen darstellen /33/. 


Dabei besteht der Zusammenhang, daß bei gleichen Reproduk- 
tionsbedingungen ein einheitliches Informationssystem reali- 
sierbar ist, jedoch gilt nicht die Umkehrung, daß bei unter- 
schiedlichen betrieblichen Reproduktionsbedingungen keine 
einheitlichen Leitungsinformationen sinnvoll sind, 

Daraus leiten sich folgende prinzipielle Möglichkeiten der 
Intensivierung ab: 
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a) die Herausarbeitung solcher Infornationsverarbeitungs- 
prozesse, die trotz unterschiedlicher betrieblicher Re- 
produktionsbedingungen rationell mit Hilfe der EDV ein- 
heitlich gestaltet werden können, 

b) eine solche Organisation der DV-Projektierung, die je- 


weils solche Betriebe in die Mehrfachnutzung arbeitstel- 
lig zu projektierender DV-Lösungen einbezieht, die eine 
hohe Übereinstimmung bzw. geringe Abweichungen der be- 
trieblichen Reproduktionsbedingungen aufweisen, 


c) die Anwendung solcher Methoden und Technologien der 
DV-Projektierung, die trotz bestimmter Abweichungen in 
den betrieblichen Reproduktionsbedingungen eine ratio- 
nelle Mehrfachnutzung gestatten. /33/ /30/ : 


Aus diesen Lösungsansätzen gehen wesentliche spezifische 
Anforderungen an die Wege zur Intensivierung des spezifi- 
schen Arbeitsprozesses "Dy-Projektierung" .hervor, auf die 
ich im folgenden unter dem Aspekt der Vereinheitlichung von 
DV-Lösungen eingehen will. 


2.5. Vereinheitlichung und variable Gestaltung von DV-Lö- 
sungen als Wege zur Schaffung mehrfach nutzbarer DV-Li- 
sungen 


Die Frage, welcher Weg, Vereinheitlichung' oder Variabilität 
gegangen werden soll, kann nicht für alle DV-Aufgaben und 
alle Betriebe gleich beantwortet werden. 

Bereits bei der Darlegung der von mir vertretenen Hauptwege 
der Rationalisierung der DV-Projektierung sind 3 praktikable 
Hauptformen der Projektgestaltung genannt worden: 


Die Projektierung von 


- Einheitsprojekten 
- teilweise variablen DV-Lösungen und 
- Variablen DV-Lösungen. /33/ 
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Die folgende Übersicht enthält die wichtigsten Weg- und 
Zielaspekte für Einheitsprojekte, 


Wegaspekte E Zielaspekte 
zentrale und/oder zentral Vereinheitlichungseffekt 
organisierte Projektier. m 


Optimale Bedingungen für 
verbindliche Mehrfachnutzung ein einheitliches (volks- 
im definierten Leitungsbe- wirtsch.) Informations- 
reich i systen 


umfassende (zentrale) Ein- 
führungshilfe und Anwen- 
dungsbetreuung 


günstige Voraussetzungen 
für die zwischenbetrieb 
che Kooperation/Integra- 
tion 


Mehrfachnutzungseffekt 
bei der DV-Projektierung 


Beschleunigung d. Projek 
tlerung 
Qualitätsverbesserung 
Kostensenkung 


lEffekte durch zentrale 
Wartung und Pflege 
Bei den anderen beiden Formen werden diese Ziele mit ande- 


ren Methoden verfolgt, auf die ich hier im einzelnen nicht 
eingehen kann. /33/ 
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Vereinheitlichungen von DV-Projekten sind an bestimnte 
überbetriebliche bzw. gesellschaftliche Organisationsfor- 
men gebunden, auf die im folgenden eingegangen werden soll, 


2.6. Rationalisierung der DV-Projektierung durch Formen 
der gesellschaftlichen Organisation 


Aus folgender Übersioht gehen die prinzipiellen Formen der 
gesellschaftlichen Organisation bei der DV-Projektierung 
hervor, 


Zentrallsation 

mit zentraler. 

Stationierung -Arbeito- 
Konzentration ger Krütto ... ee 

tion 

Zentralisation -dezentra- 

in Riohtung ler (bo- 

Kooperation triebli- 

(zentral orge- cher)Ein- 

nisiorte Koopc- satz der 

ration) Kräfte 

u. Nittel 

ooperativ 

organipiorte 

Arboitosteilung 

(Kooperation 


gemeinsohaft) 
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In der folgenden Übersicht sind theoretisch mögliche Verein- 
heitlichungsformen für DV-Projekte enthalten, deren Anwen- 

dungsbedingungen für mehrere Kooperationsbereiche untersucht 
wurden. /33/ 


Formen nach dem 
Umfang 

der Vereinheitli- 

chung 


nach der Größe 
des Bereiches bzw, 
der Zahl der einbe- 
zogenen Betriebe 


hierarchische 
Gliederungsebenen 

v. DV-Aufgaben ent- 
sprechende Umfangs- 
abgrenzungen (hori- 
zontale Begrenzung) 


Projektierungsstu- ' 
fen entsprechende 
Grenzen v. Verein- 
heitlichung. 
(vertikale Begren- 
zung) 


Formen nach dem 
Gegenstand 
der Vereinheit- 
lichung 


Formen nach der 
Art bzw, Nethode 

der Vereinheitli- 
chung 


Totale Vereinheit- 
lichung ohne 
Variabilität 


Redundante 

Vereinheitlichung \ 
Begrenzte Verein- 
heitlichung je DV- 
Projekt nit vari- 


abler betriebsspe- - . 
zifischer Ergänzung 


Partielle Vereinheit 
lichung in Form zu- 
lässiger weniger 

Grundvarianten 


In der Praxis der kooperativen Projektierung haben sich 
Formen einer annähernd totalen Vereinheitlichung in Form 
von Einheitsprojekten für einen Industriebereich sowie 
besonders Formen der redundanten Vereinheitlichung bewährt. 
Aus der Vordruckvereinheitlichung sind die beiden ‚anderen 
Formen bekannt geworden. Diese haben jedoch für eine EDV-Ko- 
operationsgemeinschaft geringe Bedeutung. /33/ 
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Es ist zu sehllen, daß sich die Konzentration nur in Form 

der Zentralisation und/oder Kooperation realisieren läßt 

und daß diese Formen letztlich zu einer aufgabenmäßigen 
Spezialisierung und Konzentration der Kräfte und Nittel füh- 
ren. 

Die Konzentration ermöglicht neben der aufgabenmäßigen bzw. 
"thematischen" Konzentration und Spezialisierung wesentliche 
Vorteile des von Marx herausgearbeiteten einfachen Konzentra- 
tionseffektes, wenn mehr Projektanten in einen \ebäude sta- 
tioniert werden, hat jedoch wesentliche Grenzen in den mate- 
riellen und personellen Voraussetzungen. /33/ 

Die Zentralprojektierung bietet günstige Möglichkeiten zur 
Realisierung der Konzentration der DV-Projektierung in einen 
Industrlebereich oder Kombinat, insbesondere mit dem Ziel der 
Entwicklung und Anwendung, einschließlich Wartung und Pflege 
von Einheitsprojekten sowie Querschnittslösungen und der Be- 
arbeitung von Schwerpunktaufgaben des gesamten Bereiches. /33/ 
Die Bedeutung der zwischenbetrieblichen Kooperation ergibt 
sich einerseits aus den Grenzen der Zentralisation und Kon- 
zentration, u. a. der materiellen Realisierbarkeit, anderer- 
seits aus der Möglichkeit, besonders die aufgabenmäßige Kon- 
zentration und Spezialisierung ohne materielle Umwälzungen zu 
realisieren. /31/ 


Die Kooperation kann als gegenwärtig wichtigste Form der ge- 
sellschaftlichen Organisation der DV-Projektierung in der 
Industrie der DDR bezeichnet werden. /33/ 

Die Organisation der zentral oder kooperativ organisierten 
arbeitsteiligen DV-Projektierung in den neu gebildeten Kombi- 
naten sollte unbedingt auf den bisherigen umfangreichen Er- 
fahrungen und wissenschaftlichen Untersuchungen aufbauen. /33/ 
Ich möchte heute einige Anregungen zu diesen Fragen aus der 
Sicht des in den nächsten Jahren zu erwartenden massenhaften 
Einsatzes von Bürocomputern geben, 
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2.7. Tragen der gesellschaftlichen Organisation der DV=-Pro- 
Jektierung unter der Bedingung des Linsatzes von Büro- 
computern 


Ieu stellt sich gegenwärtig, mit dem Beginn des massenhaften 
Einsatzes von Bürocomputern,die Frage der Bereitstellung der 
DV-Projektierungskapazität,. 


Da hiervon tendenziell Betriebe bis herunter zur Betriebsgrö- 
Se von weniger als 20 3eschäftigten betroffen werden, besteht 
das Problen, daß solche Betriebe. kaum über einen LEDV-Spezia- 
listen verfügen, obwohl die Programmierung von: Bürocomputern 
kaum geringere Schwierigkeiten aufweist, als -die ESER-Pro- 
grammierung. In diesem Zusammenhang sind n. E. die Fragen einer 
Zentralprojektierung auf der Ebene der Kombinate und Ministe- 
rien sowohl in Forn von Einheitsprojekten (einschließlich Mu- 
ster-Organisation) als auch von variablen DV=-Lösungen neu zu 
Aurchdenken. U, U. erweisen sich hierzu auch spezielle Abtei- 
lungen des Kombinates DV sowie evtl. neu zu schaffende terri- 
toriale Beratungs- und Softwarezentren, auf Dienstleistungs- 
basis und auf der Grundlage vertraglicher Bindungen als ge- 
eignete gesellschaftliche Organisationsforn, 


Aufgrund der hohen Zahl an möglichen Nachnutzungen von Soft- 
und Orgware wäre hier ein auch fachlich und vom erzielbaren 
Nutzen her interessantes Betätigungsfeld für hochqualifi- 
zierte Spezialisten als Org- und Software-Berater und -Ent- 
wickler denkbar. Dadurch könnte das nm. E. vorhandene diesbe- 
zügliche Vakuum bei den Kleinbetrieben volkswirtschaftlich 
mit geringstem Arbeitsaufwand gemindert werden, 

Eine ausschließlich oder weitgehend betriebliche Einsatzvor- 
bereitung kann m. E. auf keinen Fall für eine Betriebsgröße 
bis zu wenigen 100 Beschäftigten vertreten werden,. 

Auf die von mir skizzierte Weise wäre auch eine u. U, jahr- 
zehntelange thematische Spezialisierung auf einzelne Sachge- 
biete, z. B. ein "Informationssysten für Katerial- und Lager- 
wirtschaft" möglich, wodurch ein normaler effektiver Lernpro- 
zeß aus den vorangegangenen Einsatzvorbereitungsfällen nög- 
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lich wird. Wenn man dazu noch die Spezialisten für ein Sach- 

gebiet strukturell und lokal zusammenfaßt, wird allein durch 

diesen thematischen Konzentrationseffekt der eindeutige Vor- 

teil für den Auftraggeber, u. U, auch für einen Exportkunden 

deutlich, Analog sollte die Frage der Organisation gesehen 

werden: ein solches Organisations- und Software-Beratungs- 

büro sollte mit den so stets vorhandenen Erfahrungen in der 

Lage sein, einen Kleinbetrieb in kurzer Zeit relativ komplex 

mit Mitteln der Organisation und IV=-Technik zu rationalisie- 

ren, die Belegschaft zu schulen und sich dem nächsten Betrieb 

im Territorium bzw, Kombinat zuzuwenden. 

Dazu muß jedoch eine neue Kooperationskette zwischen 

- Hersteller der Hardware, 

- Hersteller der Grundsoftware, 

- Org- und Software-Beratungsbliro (als gleichzeitigem Appli- 
kationssoftware-Entwickler) und- 

- Anwenderbetrieb 

hergestellt ‚werden. Durch diese Kette mußddie Bereitstellung 

der Hard- und Software spätestens denn gesichert werden, wenn 

dies im Vertrag mit dem Anwenderbetrieb vereinbart wurde, so 

daß das Beratungebliro auch die Funktionsfähigkeit und den 

Nutzen des neuen Organisationssystens nachweisen kann. 


3. ZumgVerhältnis von Organisations- und DV-Projektierung- 
Stellungnahme zum "Leitfaden Organisationsprojektierung"- 


IRRBEN 6.1 KOBEINENOEERE EINEN PESENEENEEREONERREEEEER NRNE REISEN EEE ASESENERRENENEREER 


Das Anliegen des Autorenkollektivs, mit dem Leitfaden einen 
Beitrag zu planmäßiger und systematischer Organisationsarbelt 
zu leisten, muß auch von allen Fachkollegen, die sich mit der 
DV-Projektierung beschäftigen, unterstützt werden. Ich möchte 
an dieser Stelle nur auf meinen Haupteinwand eingehen: 

Dieser besteht darin, daß die DV-Projektierung als Teilge- 
biet der Organisationsprojektierung aufgefaßt wird. und 
phasenverschoben nach den ersten sogenannten O-Stufen be- 
ginnt. 
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Das bedeutet, daß die Aufgabenstellungen für alle DV- Anwen- 

dungen, letztlich auch ein komplexes AiSU, vor der DV-Projek- 

tierung konzipiert und als Vorgabe an die LEDV-Organisation 

(vgl. S. 47, 5. 64) übergeben werden, wobei 1t. Leitfaden 

uU. a. folgende Teillösungen der DV-Projektierung vorgegeben 

werden sollen; 

- ein "Makroalgorithnus", 

- ein "Mikroalgorithnus", 

- weitere bisher in der DV-Projektierung in den Stufen b1 bis 

E3 gelöste Aufgaben, wie Schlüssel- und Vordruckgestaltung. 

Dies bedeutet: 

a) einen sehr hohen Bedarf an solchen universellen Orgspezia- 
listen 

b) ein späteres Eintakten der EDV-Organisatoren in den Pro- 
jektierungsprozeß und deshalb lange Einarbeitungszeit oder 
geringe Problemkenntnisse der EDV-Organisatoren, d. h. 
Nachteile bei der DV-Projektierung. 

Dabei ergibt sich die prinzipielle Frage, ob ein Nicht-EDV- 

Spezialist die Frage der Automatisierbarkeit und Automati- 

sierungswürdigkeit a priori besser lösen kann als ein EDV=- 

Organisator während der DV-Projektierung? Dagegen sprechen 

einige Argumente, u. ae: 


a) die komplizierter werdende Informationsverarbeitungs-Ge- 
rätetechnik, 

b) der steigende Anteil der Software am Gesamtaufwand. Die 
Automatisierungswürdigkeit /41/ hängt danit primär von 
der Existenz und Anwendbarkeit bzw. rationellen Nöglich- 
keit der Eigenentwicklung geeigneter Grund- und Applika- 
tionssoltware ab. 

Deshalb sollten meiner Ansicht nach die Fragen der Automati- 

sierungswürdigkeit durch ein interdisziplinäres Projektanten- 

kollektiv beantwortet werden, 
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Meines Erachtens sind Unterstützungsaktivitäten der Leitungs- 
und Büroorganisatoren zweckmäßiger als eine zeitliche Tren- 
nung dieser Organisation von der DV-Organisation. Ein solches 
Vorgehen ist n. E. ein Grundgedanke der ASU-Projektierung /1/, 
bei der ASU-Teilsysteme durch ein ASU-Projektantenkollektiv 
aus Spezialisten mehrerer Disziplinen simultan und komplex be- 
arbeitet werden, 

Daraus ergibt sich folgender Vorschlag zur Einbeziehung unter- 
schiedlicher Spezialisten in die ASU- bzw. EDV-Projektierung 
für ein Teilsysten: 


ORZ ASU/EDV Konz.l|_ 
Planung u 
) 
- Ri . ze 1 
Fachbereich| |Leitungs- EDV- (bzw. ASU-) Ja 
(FB) Betriebs- und: Projektierung Rechenzentr.| ı 
Büroorganisat, 
| 
Teilsysten Teilsysten Systen- - 
4 rg programmierer| | 
ZeBe z.B. Grund- Spezialisten a 
Produktion fondswirtsch, f.IV-Technik 


Spezialist f., Themenleiter 
IV-Technik 


Leitungs-, Betriebsorganisator 


(evtl. konsultativ) Biroarganisater 
Systemprogramnierer 

evtl. Fachbereichsorganisation: von E1- 
in E4 mind. konsul=- ' E6 


Sau FB-NMitarbeiter 
Anwendungsprogran. EDV-Organisator (en) 


(E3 - 55, Schwer- EDV-Projektanten (E1, E2 ... E6) 
punkt E4) \ 


(zeitweilig) 
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Einige Schlußfolgerungen: 


Aus meinen Darlegungen leitet sich die These ab: 
DV-Projektierung muß stets gleichzeitig als Org-Projek- 
tierung aufgefaßt werden. 


Die ersten Projektierungsstufen sollten neben der stets ge- 
botenen Einbeziehung der betreffenden Fachbereiche eine Ge- 
meinschaftsarbeit von Leitungs- sowie Büro- und EDV-Organi- 
satoren sein. Dabei kann man dort, wo der EDV-Einsatz zeit- 
weilig nicht vordergründig gesehen werden kann, zunächst 
durchaus von "Organisationsprojektierung" reden. Die 0-Stu- 
fen sollten jedoch nur für die Teile des Projektierungsge- 
genstandes weitergeführt werden, für die kein EDV-Projekt 
erarbeitet wird, Daraus ergibt sich als weitere Folgerung: 
Die Dokumentationen der ersten 0- und E-Stufen sollten so- 
weit wie möglich übereinstimmen, um Doppelarbeiten zu ver- 
meiden, 

Deshalb sollte von EDV- und Organisationsspezialisten ge- 
meinsam an der weiteren Präzisierung des Leitfadens zur 
Orgenisationsprojektierung für den genannten Anwendungsbe- 
reich gearbeitet werden, 


4. Organisationsarbeit als Objekt der EDV-Anwendung (rechner- 
gestützte Organisationsarbeit) 


Organisationsarbeit als Überwiegend geistig-schöpferische 
weitgehend entwerfende, planende, gestaltende Tätigkeit nit 
diesbezüglichen Parallelen zur DV-Projektierung nuß wie jede 
gesellschaftliche Arbeit selbst rationell gestaltet werden. 
Aus meiner Sicht ergeben sich folgende Schwerpunkte einer 
künftigen Rechnerstützung für die Organisatorentätigkeit: 
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1. Die umfassende Anwendung von universellen Textbe- und =-ver- 
arbeitungssystemen als erster und vielleicht schon für die 
nächsten 5 - 6 Jahre wichtigster Schritt, um Org- und Ar- 
beitsanweisungen und organisatorische Regelungen rationell 
formulieren und warten zu können, 


2. Die Schaffung spezieller Verwaltungs- und Kontrollsystenme 
für Dokumentationen von organisatorischen Lösungen. 


3s Die Entwicklung eigens für die Organisatlionsarbeit zu 
schaffender Fachsprachen und geeigneter Software für die 
Formulierung organisatorischer Sachverhalte und die er- 
forderliche synthaktische und teilweise semantische 
Prüfung. 


4. Die Anwendung der grafischen Datenverarbeitung für die 
Darstellung von Prozessen und Strukturen. 


5. Die Formalisierung typischer organisatorischer Fragestel- 
lungen und von Algorithnmen für rechnergestützte Entschei- 
dungshilfen bei der Organisationsarbeit, 


6. Die umfassende Nutzung der betrieblichen DV-Systeme, z. B. 
von Datenbanksystemen, auch zur Vorbereitung organisa- 
torischer Entscheidungen, 


Dabei können m. E, viele Hilfsmittel, die für die rechnerge- 
stützte DV-Projektierung genutzt werden, 'auch für die Lei- 
tungs- und Büroorganisation angewandt werden. 
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5. Einige methodologische Zusammenhänge zwischen Organi- 
sation und DV=-Projektierung und daraus resultierende 


Schlußfolserungen 


m 


Begriffe wie Nutzerakzeptanz, Nutzerfreundlichkeit und 
"yiensch-Maschine-Synbiose" /17/ weisen seit Ende der 70er 
Jahre auf ein neu entstandenes Problem in der Automatisie- 
rung der Informationsverarbeitung hin: auf das Problem der 
kiensch-laschine-Kommunikation, wobei Güie Arbeit des Menschen, 
sein Arbeitsprozeß als primär anzusehen ist. /29/ 

Die von GRIESE und ÜSTERLE /17/ vertretene neue Spezialisie- 
rung in Form eines Requirements Tngeneering sollte uns in 
diesem Zusammenhang nicht, unbedingt darauf hinweisen, eine 
neue Ingenieurdisziplin für die Fragen der Arbeitsorgani- 
sation und Arbeitsbedingungen im Zusammenhang nit der Dialog- 
verarbeitung zu schaffen, sondern die EDV-Organisatoren bzw, 
DV-Projektanten auf diese Aspekte stärker zu orientieren. 


/29/ 


Un die Frage der Spezialisierung innerhalb der DV-Projektie- 
rung in Anwenderbereichen aus meiner persönlichen Sicht zu 
beantworten, möchte ich hier bewußt zwischen zwei Extremen 
unterscheiden: 


- einerseits großen betrieblichen zentralen oder territorialen 
Projektierungskollektiven und i, d. R. größeren Projekt- 
komplexen und Betrieben als Gegenstand und 
größeren EDVA als Nittel und 

-. andererseits sehr kleinen Projektierungskollektiven Für 
Kleinbetriebe mit dem primären littel Bürocomputer, 


Für den‘ersten Fall habe ich zur Entwicklung organisaätori- 
scher Spezialdisziplinen bereits Aussagen gemacht. 

Auf der Seite der DV-Spezialisten, also der Angewandten Infor- 
mationsverarbeiiung, sehe ich primär eine Spezialisierung in 
Form Tolgender Disziplinen als sinnvoll an: 
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1, EDV-Organisatoren (Organisationskenntnisse, Kenntnisse auf 
dem Fachgebiet, Kenntnisse der Anwendungsprogrammierung), 


2. Anwendungsprogramnierer bzw, pplikatlons=software=Inge- 
nieure (Kenntnisse auf dem Gebiet des Software-Ingenieur- 
wepens, Kenntnisge auf dem Fachgebiet, geringe kenntnisse 
anf organisaterischen Gebiet), 


3. SystensoftwarerIngenieure (Systemprogrammierer, Spezia- 
listen für Entwurf, Implementierung und Test großer Pror 
gramnsysteme), 


4. PV-Projektanten (Spezrialisierungsrichtung mit Kenntnissen 
der EDV-Organisation und der Anwendungaprogramalerung (Soft- 
ware=Entwurf, mimplementierung und Test) i, d». R. in 
höheren Programniersprachen), 


Der Anteil der einzelnen Disziplinen aollte je nach Projekr 
tierungaopjekt differengiert werden. Meiner Ansicht nach 
braucht lediglich der unter 3, genannte SaftwarerIngenieur 
bzw, Systemprogrammierer eine Ausbildung in Informationer 
verarbeitung, wie sie in den belden Drasdener Sektionen er- 
folgt, für die 2, Kategorie ersaheint deren Einsatz möglich. 
Jeweiligen Anwendungsgebiet nach den Richtlinien der im RGW 
abzeatimmten ASU-Kadergruppe IVa ausgebildet werden, wobei 
ein IV-Anteil von 25 % den Studiums eanaustreben ist, 

Bei EDV-Organisatoren halte loch eine von vornherein organi- 
satlionawissenachaftlich orientierte Ausbildung, ähnlich der 
an der Humbaldt=Universität existierenden für Wissenschafts" 
prganisatoren, für zweakmäßigy 

Für große Bereiche der Teohnischen Vorbereitung, £e B« große 
Ronstruktiona= und Projektierungsblüros, erscheinen salche 
Wissenschaftsorganisatoren mit einer IVrVertiefung /40/ aua 
meiner Sicht besonders geeignet, 

Für Kleinbetriebe, besonders für den Einsatz von Büroconr 
putern in Kleinbetrieben, erscheint der relativ universell 
einsetzbare DY-Projektant, unterstützt von einem Büroorgani- 
sator, die zweckmäßigste Spezialisierungsforn. 
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Geht man von der Notwendigkeit der Realisierung der DV-Pro- 
jektierung als interdisziplinäre Aufgabe aus, da sonst i. d. 
R. entweder schlechte. Software- oder nicht befriedigende 
Orgware entsteht /17/, ergibt sich, daß für diese interdis- 
ziplinäre Arbeit auch eine einheitliche Technologie und eine 
einheitliche technerstützung erforderlich ist, Da DV-Projek- 
sierung in den meisten Applikationen nur schätzungsweise 

40 - 60 % Software-Ingenieur-Arbeit, ansonsten aber Organi- 
sationsarbeit darstellt, erweisen sich Versuche, die gleichen 
Technologien des Software-Ingenieurwesens, wie sie bei reinen 
Software-Produzenten notwendig sind, unvermittelt und unge- 
filtert den Anwenderbetrieben anzubieten, als problematisch, 
Dies zeigt sich sehr deutlich in Versuchen, z. B,. unter- 
schiedliche Programnentwicklungsmethoden, wie die Jackson- 
Methode, funktionsorientiertes Entwerfen und andere mög- 
lichst parallel dem gleichen Projektanten zur selbständigen 
Auswahl anzubieten, Verwaltungssysteme für Aufgabenstellungen, 
überhaupt Aufgabenstellungen aus der Rechnerstützung jedoch 
auszuklammern. Spezielle für die Organisation geeignete Ent- 
wurfsmethoden, wie die SADT-Nethode, wurden aus der bisherigen 
Diskussion meist von vornherein ausgeklammert,. Wenn der DV- 
Projektant auch Organisator sein soll, muß ihm auch zuge- 
standen werden, nicht das Software-Entwicklungswissen eines 
spezialisierten Software-Ingenieurs zu haben, Aus dieser 
Sicht müssen software=-technologische Fragen in engeren Zu-= 
samnenhang zu orgware-technologischen in Prozeß der DV-Pro- 
jJektierung betrachtet werden. Daraus ergibt sich zunächst 
einmal die Forderung an die Organisationswissenschaft, aber 
besonders an die wissenschaftliche Eethodologie der DV-Projek- 
tlierung, diese, die EDV-Organisation betreffenden Teile der 
DV-Projektierung im Sinne einer Technologie, die die Aspekte 
der Rechnerstützung von vornherein einbezieht, weiterzuent- 
wickeln. Wichtig erscheint dabei, daß die verwendeten Instru- 
mentarier von der Organisationsanalyse bis hin zum Programı- 
entwurf und zur Projektdokumentation aufeinander abgestinnt 
sind und einen nahtlosen Übergang zwischen den einzelnen Be- 
arbeitungsstufen ermöglichen, 
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In diesem Sinne sind sowohl die existierende Rahmenmethodik 
der DV-Projektierung als auch entwickelte softwaretechnolo- 
gische Ansätze neu zu durchdenken, da DV-Projektierung sich 
eben nicht auf das Software-Ingenieurwesen beschränken läßt, 
sondern eine immer bedeutendere Orgware-Komponente haben wird. 


Verfasser: Prof.Dr.sc. Köhli, Siegfried 
Ingenieurhochschule Köthen 
Abt. Hathematik/Rechentechnik 
WB Informationsverarbeitung 


4370 _ Köthen 
Bernburger-Str.52-57. 
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Dipl.-Math. Hans Winks, Humboldt-Universität 


SPOOL - ein System zur Automatisierung von Produktionsprozessen 
en ESER-Rechnern 


- Entwicklungsstand und Entwicklungsrichtungen - 


Die EDV=-Anlagen, die zur Zeit in der DDR eingesetzt werden, haben 
eine hohe Stufe der Leistungsfähigkeit erreicht. Insbesondere die 
Anlagen des ESER I und des ESER II prägen in vielen Großrechenzen- 
tren Arbeitsorganisation, Projektierungs- und Programmierungsstil, 
wobei z.B. auf dem Gebiet der Rationalisierung datenintensiver Pro- 
zesse in den letzten Jahren große Fortschritte zu verzeichnen sind. 


Auf diesen Anlagen wird zur Zeit überwiegend das Betriebssysten 
0OS/ES mit den Steuerprogrammkonfigurationen MVT und MFT eingesetzt. 
Dieses Betriebssystem bietet sowohl den Nutzern als auch den Anla- 
genbedienern umfangreiche Möglichkeiten zur Steuerung der Jobabar- 
beitung in der EDVA und hat sich deshalb als das bisher leistungs- 
fähigste Betriebssystem für die mindestens bis 1990 eingesetzten 
ESER-Anlagen erwiesen. Trotz des hohen Leistungsgrades der ESER-EDVA 
wird vielerorts daran gearbeitet, durch noch bessere Auslastung der 
Ressourcen einen Produktivitätszuwachs zu erreichen. Dabei geben die 
Beschlüsse und Orientierungen des X. Parteitages der SED und des 

10. Kongresses des FDGB die Richtung an, nämlich durch Intensivie- 
rung der Nutzung der hochproduktiven Anlagen und Investitionsobjekte 
eine Steigerung der Arbeitsproduktivität zu erreichen. 


Einerseits durch die Vielfalt und die Komplexität der teilweise eine 
recht detaillierte Systemkenntnis voraussetzenden Möglichkeiten des 
0OS/ES, enderereeits durch eine mangelnde oder fehlende Unterstützung 
wesentlicher Prozesse im Rechenbetrieb außerhalb der unmittelbaren 
Jobverarbeitung in der EDVA und nicht zuletzt durch eine unzureichen- 
de Orientierung auf Vereinfachung, Produktivitätssteigerung und Au- 
tomatisierung der Abläufe im Umkreis der EDVA ergeben sich Grenzen 
bezüglich der Erhöhung der Gesamteffektivität und damit Ansätze für 
die Entwicklung zusätzlicher Systemsoftware. Es seien an dieser 
Stelle einige Probleme genannt, die aus Effektivitäts- und Zuverläs- 
sigkeitsgründen einer rechnergestützten Lösung bedürfen. 


I. 


II. 


III, 


IV. 
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Für die Organisation eines reibungslosen Stapelbetriebes ist 

ein beträchtlicher Arbeitsaufwand in der Arbeitsvor- und 

-nachbereitung nötig. Insbesondere betrifft das die während 

der Jobvorbereitung vorzunehmende Auswertung der üblichen Job- 

begleitkarten, die notwendig ist 

- für die Zusammenstellung der Jobs nach bestimmten, für die 
Abarbeitung vorteilhaften Gesichtspunkten (z.B. Datenträger- 
nutzung), 

- für die Prüfung der Berechtigung der Nutzung der verschiede- 
nen Rechnerressourcen (z.B. Zeit, Datenträger, Dateien) 
durch die Jobs. 


Auf Grund der erwähnten Komplexität des OS/ES ist der Bedien- 
aufwand und der Einfluß der Bediener auf die Gesamtproduktivi- 
tät der Anlage recht groß, insbesondere dann, wenn Aufgaben 

der Arbeitsvorbereitung vom Bedienpersonal wahrgenommen werden. 
Der Arbeitsablauf und die Anforderungen der Nutzerjobs bzw. des 
Betriebssystems an die Bediener erfordern deren ständige Auf- 
merksamkeit. Das OS/ES bietet von sich aus kaum Möglichkeiten, 
durch eine geeignete Jobauswahl die Abarbeitung des Jobstromes 
8so zu gestalten, daß Bedienhandlungen minimiert werden (z.B. 
Datenträgerwechsel) bzw. daß Bedienhandlungen auf bestimmte Ta- 
geszeiträume konzentriert werden, um das Bedienpersonal sowohl 
zahlenmäßig als auch bezüglich der Arbeitsintensität effekti- 
ver einsetzen zu können. 


Die Anlagenbedienung weist unter OS/ES einige Unbequemlichkei- 

ten und Schwächen auf. Das betrifft zum Beispiel: 

- die Informationsmöglichkeiten für die Bediener über die Jöbs 
(Jobbegleitkarte), 

- das zeitaufwendige Realisieren von lNaßnahmen, die mehrere 
Jobs oder Geräte betreffen (nur Kommandos für einzelne Objek- 
te), 

- die Arbeit nit privaten Prozedurbibliotheken, 

- die Möglichkeiten zur Steuerung der Ausgabe der Drucklisten 
insbesondere bei Havarien am Drucker (Papierriß oder -stau). 


Das OS/ES bietet für die optimale Ausnutzung der verschiedenen 
Ressourcen nur eine mehr oder weniger geringe Unterstützung. 
Eine effektive Ausnutzung ist in hohem Maße abhängig von der 
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Aufmerksamkeit und Qualität der Anlagenbedienung, von einer 
durchdachten und wirksamen Produktionstechnologie (Datenträger- 
und Dateiverteilung, Jobklassenverteilung u.a.) und vom Quali- 
fikationsniveau der Nutzer. Schwierigkeiten bestehen bekannt- 
lich im Ausgleich zwischen E/A- und zentraleinheitsintensiven 
Aufgaben, in der Ausnutzung des peripheren SYSDA-Direktzu- 
griffsspeichers, vor allem aber hinsichtlich einer günstigen 
Verteilung der Nutzerdateien auf den Magnetdatenträgern (Spei- 
cherplatzausnutzung, Vermeiden des Wechselns von Datenträgern). 


V Das OS/ES bietet nur unzureichende bzw.. kaum praktikable Un- 
terstützung für den Schutz und die Sicherung der Dateien. Die 
konventionellen Möglichkeiten des Verfallssthutzes oder des 
Schutzes über Kennwort sind mit einem hohen Aufwand bei der 
Bedienung der EDVA ‘verbunden und werden deshalb nur selten ge- 
nutzt. 


VI. In den letzten Jahren ist eine zunehmende Nutzung von Dialog- 
und Jobeingabesystemen zu beobachten. Auf Grund der räumlichen 
Trennung zwischen jobabsendenden Terminalnutzern und der emp- 
fangenden EDVA ist eine Aufgabenbeschreibung in Form einer Be- 
gleitkarte nicht möglich, sodaß die aus dem Fehlen dieser Be- 
gleitinformationen resultierenden Schwierigkeiten zur Zeit nur 

\ durch zusätzliche Restriktionen an die abgesandten Aufgaben 
abgefangen werden können, 


Die genannten Probleme zur Automatisierung und effektiveren Organi- 
sation des Produktionsbetriebes an ESER-Anlagen unter dem OS/ES 
sind sehr komplexer Natur. Einige Aspekte der vorgenannten -Schwie- 
rigkeiten sind durch Einzellösungen hier und da schon erkannt und 
bewältigt. Doch ist die Anwendung vieler einzelner Zusatzprogramme 


i.a. unrationell. 


Davon ausgehend wurde in Zusammenarbeit zwischen Organisations- und 
Rechenzentren der Humboldt-Universität zu Berlin und der -Martin- 
Luther-Universität Halle das System SPOOL als eine dem Betriebssy- 
stem OS/ES nebengeordnete Komponente zur Automatisierung, Produkti- 
vitätssteigerung und Rationalisierung des Produktionsprozesses an 
ESER-Rechnern entwickelt, Die Entwicklung dieses Systems erfolgte 
bisher in mehreren aufwärts kompatiblen Stufen SPOOL 1, SPOOL 2.0 
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Das Basissystem SPOOL 1 dient vorrangig der Rationalisierung der An- 
lagenbedienung, der Jobverwaltung und der. effektiven Parallelarbeit 
‚der Zentraleinheit mit den externen Geräten. Es befindet sich seit 
1980/81 in mehreren Hochschulrechenzentren im permanenten produkti- 
ven Einsatz. Die nit dem Einsatz des Systems verbundene Steigerung 
des Jobdurchsatzes ist abhängig von dem Anlagentyp, der Peripherie 
der Anlage und der Hauptspeichergröße und beziffert sich auf 5 bis 
15 % 


Seit Januar 1982 wird die Version SPOOL 2.0 produktiv am Organisa- 
tions- und Rechenzentrum der Humboldt-Universität mit dem Ziel ein- 
gesetzt, bei gleichbleibender Bedieneranzahl vom unterbrochenen 
Dreischichtbetrieb zum durchgängigen Dreischichtbetrieb überzugehen. 
Durch neue -Komponenten zur Datenträgerverwaltung, Jobklassifizierung, 
Jobauswahl und zur Automatisierung der Konsolbedienung ist software- 
'seitig die Möglichkeit gegeben, 


- die EDVA zeitweise (über mehrere Stunden) ohne Bedienereingriff 
zu betreiben, 

- generell die Anlagenbedienung bezüglich der Magnetplattenauswahl 
zu optimieren und 

- die Jobauswahl in Abhängigkeit von der Verfügbarkeit der benötig- 
ten Magnetdatenträger zu steuern. 


In der Perspektive sind im Zusammenwirken mehrerer Hochschuleinrich- 
tungen die Erweiterung des Systems SPOOL mit Datenträger- und Datei- 
verwaltungskomponenten (Bereitstellung, Auslagerung und Sicherung 
von Magnetplattendateien), die Unterstützung der lokalen Mehrrech- 
nerkonfiguration durch SPOOL sowie der synchrone und asynchrone An- 
schluß von Stapelterminals als Endstellen eines sternartigen Rech- 
nerverbundes vorgesehen. Der Einsatz des Systems SPOOL unter der 
Steuerprogrammkonfiguration SVS wird untersucht. 


Das System SPOOL arbeitet als selbständige Aufgabe im Betriebssystem 
OS/ES (MVT, MFT). Dabei hat es sowohl bestimmte Arbeiten der Job-, 
Aufgaben- und der Datenverwaltung des 0OS/ES zu übernehmen als auch 
Funktionen der Automatisierung der Arbeitsvorbereitung sowie der 
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Arbeitsvorbereitung sowie der Rationalisierung und Automatisierung 
der Bedienung der EDVA wahrzunehmen. 


Als eine Grundfunktion übernimmt SPOOL die Jobeingabe (Kartenleser, 
MB, MP) und die Jobausgabe (Drucker, Stanzer, MB). Dabei werden ei- 
ne maximale Arbeitsgeschwindigkeit, eine zentrale rationelle Zwi- 
schenspeicherung der eingelesenen Jobs und der erzeugten Jobausga- 
ben (keine Zerstlickelung des SYSDA-Speichers), eine ständige Wie- 
deranlauffähigkeit für Jobs, die sich in der Ausführungsphase be- 
finden, und vor allem ein hoher Druckkomfort (Vor- und Rückwärts- 
positionieren, Unterbrechung, Wiederanlauf und Druckwiederholung) 
gewährleistet. Eine weitere Grundfunktion hinsichtlich der Jobver- 
waltung - die rationelle Gestaltung der Bedienung -— wird durch die 
Kommandosprache von SPOOL erreicht. Durch entsprechende bequem an- 
wendbare SPOOL-Kommandos werden die meisten OS/ES-Kommandos (insbe- 
sondere Kommandos, die die Jobverwaltung steuern oder Informationen 
Über Jobketten usu. liefern) ersetzt und dabei zum Teil in ihrem 
Funktionsumfang erweitert. Die SPOOL-Kommandos aktivieren und Steu- 
ern auch die zusätzlichen Funktionen des Systems SPOOL. Zur Unter- 
stützung der Arbeit der Anlagenbedienung und ggf. der Arbeitsvorbe- 
reitung liefert SPOOL eine Jobinformationsliste (s. Abb. 1). In ihr 
sind die für Arbeitsvorbereiter und Bediener wichtigen Jobparameter 
verzeichnet, Dazu gehören: 


- die intern verwendete Jobnummer, welche zur leichteren und 
schnelleren Bedienerkommunikation vom System SPOOL vergeben 
wird. Der Bediener kann in SPOOL-Kommandos diese Jobnumer 
(einzeln oder für ganze Gruppen) verwenden; 

- Jobname, 

- Jobklasse, 

- Auftragsnummer, 

- Programmierername, 

- benötigter SYSDA-Arbeitsspeicher, 

- Datenträgerarchivnummern, 

- Namen bzw. Adressen direkt angesprochener Geräte, 

- Namen der verfallsgeschützten Dateien, die überschrieben werden 
sollen; 

- Wiederholbarkeit des Jobs sowie 


- spezielle Anforderungen an die Bedienung. 
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Abb. 1 
JOB INFORMATION 30.JUL.1982 11.52.26 
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yonınE TABLE INFORMATION 30.JUL. 1982 11.52.26 


VOLUME WITH OPERATOR NO OPERATOR SUMMARY 

SERIAL DUR JOBS DUR JOBS DUR JOBS 
HPMO41 (6) 16) 41 1 41 1 
HPMO5O 10) 0) 0 16) 0 19) 
HPMO33 25 1 41 1 66 2 
HPMO32 20 1 [B) N 20 1 
036 16) 1e) 0 [e) 0 6) 
HPMO48 16) 10) 0 0 1e) 19) 
HPMO49 40 1 d) [e) 40 1 
HPMO36 80 1 16) 19) 80: 1 
HPMO31 15 0 0 0) 15 0) 


END OF VOLUME TABLE INFORMATION 
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Um dem Bediener die Konfigurierun. der Magnetplatten zu erleichtern, 
enthält die Jobinformationsliste zusätzlich zu jeder Magnetplatte, 
die von Jobs benötigt wird, Angaben über die Anzahl und die geschätz- 
te Laufzeit aller sich auf sie beziehenden Jobs. Alle diese Angaben 
werden der JOB-Anweisung des OS/ES und speziellen, durch die Nutzer 
bereitzustellenden SPOOL-Steueranweisungen (s. 3.3.) entnommen. Ei- 
ne weitere wesentliche Funktion, die ebenfalls schan in der Version 
SPOOL 1 realisiert ist, ist die Prioritätensteuerung. SPOOL steuert 
die Auswahlpriorität zur Verarbeitung (Jobpriorität), die Auswahl- 
priorität während der Verarbeitung (Verarbeitungspriorität) und die 
Auswahlpriorität zur Jobausgabe (Ausgabepriorität). Bei der Verwen- 
dung von Standardwerten bei der Generierung des Systems SPOOL wird 
die Jobpriorität in Abhängigkeit von den durch den Nutzer in einer 
SPOOL-Steueranweisung kodierten geschätzten Joblaufzeit und Druck- 
zeilenanzahl so gebildet, daß der Expreßbetrieb bevorzugt wird. 
SPOOL veranlaßt, daß niedrige Werte für Laufzeit und Druckzeilen zu 
einer hohen Priorität führen und umgekehrt. Es ist möglich, daß der 
Bediener während der Abarbeitung des Jobs bei Überschreiten der 
Schätzwerte zyklisch informiert wird und daß generierungsabhängig 

im gegebenen Fall das Beenden des Jobs (automatisches CANCEL) durch 
das System bei Überschreiten der Schätzwerte veranlaßt wird. Die 
Bevorzugung des Expreßbetriebes wird standardmäßig auch bei der Bil- 
dung der Ausgabepriorität durchgeführt, wobei als bestimmender Para- 
meter die tatsächliche Druckzeilenzahl des Jobs verwendet wird. Wäh- 
rend der OS/ES-Verarbeitung der Jobs überwacht das System SPOOL de- 
ren E/A- und Zentraleinheitsbelastung und modifiziert dynamisch in 
festgelegten Zeitabständen die Verarbeitungspriorität der Aufgaben 
derart, daß Jobs mit einer hohen E/A-Rate und niedriger Zentralein- 
heitsbelastung bevorzugt werden. 


Ein weiterer Komplex von Funktionen, der ab der Version SPOOL 2.0 
eingeschlossen ist, befaßt sich mit der "Automatisierung der Anlagen- 
bedienung, insbesondere mit den Möglichkeiten, die EDVA zeitweise 
ohne Bedienereingriff zu betreiben. 


Durch das System werden drei verschiedene, durch Kommando zu akti- 
vierende Betriebsweisen realisiert, deren wesentliche Unterschiede 
vor allem in einer Jobauswahl liegen: 


Bi Abarbeitung von Jobs, die Bedienereingriffe erfordern; 
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B2 Abarbeitung von Jobs, die keine Bedienereingriffe erfordern; 
B3 Abarbeitung aller Jobs - unabhängig von ihren Bedienanforderun- 
gen. 


In allen drei Betriebsweisen gelangen standardmäßig nur solche Jobs 
zur Ausführung, deren benötigten Magnetplatten dem System durch ein 
spezielles Bedienkommando als logisch verfügbar gekennzeichnet wur- 
den. e 


Das System SPOOL 2.1 befaßt sich zusätzlich nit der Unterstützung 
solcher Funktionen, die Arbeitsgänge der Arbeitsvorbereiter automa- 
tisiert. Durch die Verwaltung eines Katalogsystens ist SPOOL in der 
Lage, die Berechtigung zur Inanspruchnahme folgender Ressourcen 
durch die Jobs zu überprüfen: Rechenzeit, Druckerpapierverbrauch, 
Magnetdatenträger und Dateien. Die beabsichtigte unberechtigte Nut- 
zung von Ressourcen, ZB. bei überschrittenem Rechenzeit- oder Pa- 
pierkontingent oder bei Zugriff zu Dateien, für die der Nutzer 
(Auftragsnummer) nicht autorisiert ist, führt zum Entfernen des ent- 
sprechenden Jobs (automatisches CANCEL) aus dem System, bevor seine 
eigentliche Abarbeitung beginnt. Durch die Überwachung des Dateizu- 
eriffs wird die Anwendung der OS/ES-Schutzmechanismen überflüssig 
und es entfallen somit auch diesbezügliche Bedieneraktivitäten. 


Durch eine Angleichung der entsprechenden TSO-Komponenten /2/ ist 

es möglich, die Systeme TSO und SPOOL parallel laufen zu lassen. 

Es wurde abgesichert, daß delegierte Jobs sich in das technologische 
Schema einpassen können und somit wie Jobs behandelt werden, die 
über die Auftragsannahme an die Anlage gelangen. 


Das SPOOL-System besitzt als Front-End-Prozessor auch die Möglich- 
keit, von intelligenten Stapelterminals, Jobfernverarbeitung zu be- 
treiben. Zur Zeit liegen nur für solche Terminals Anschlußmöglich- 
keiten vor, die über Synchronleitungen angeschlossen werden können 


/3/. 
Weitere Entwicklungen im Rahmen der SPOOL-Bearbeitung sind: 


- die Realisierung einer lokalen Mehrrechnerkonfiguration, die die 
lokale Kopplung von zwei ESER-Rechnern über einen Kanal-Kanal- 
Adapter unter der Bedingung einer Bedienbarkeit von einer Anlage 
aus bieten soll, 
und 
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- die Automatisierung der Datelbereitstellung, die der rationellen 
Verwaltung großer WPS unter Zuhilfenahme von Hintergrundspeichern 
(MB-Archiv) dienen soll und die sich als SPOOL 3 in der Realisie- 
rungsphase befindet /4/. 


! 
Zusammengefaßt ergeben sich bei Einsatz der bereits fertiggestell- 


ten Teile des Systems SPOOL folgende Effekte: 


- Erhöhung des Jobdurchsatzes; 

- starke Verringerung des Arbeitsaufwandes in der Arbeitsvorberei- 
tung; 

- erhöhte Sicherheit der Ressourcennutzung; 

- effektivere Arbeit des Bedienpersonals; 

- Durchführung eines zeitweise bedienerlosen Betriebes und damit 

- Verringerung des Aufwandes an Bedienpersonal bzw. Verlängerung 
der produktiven Einschaltzeit der ESER-Anlage bei gleichbleiben- 
der Anzahl der Bediener. 


3. Aufbau und Arbeitsweise des Systems _SPOOL 


Die Funktionen des Systems SPOOL werden durch eine Reihe von Pro- 
zessoren realisiert, die durch einen zentralen Dispatcher über eine 
interne WALT-POST-Logik mit Zentraleinheitszeit versorgt werden. In 
wesentlichen handelt es sich dabei um die Prozessoren 


- Eingabeprozessor(en) (RDR) für die Realisierung der Jobeingabe; 

- Prüfprozessoren (CHK) für die Ressourcenprüfungen; 

- Initiatorprozessoren (XEQ) für die Jobauswahl und die Absicherung 
weiterer Maßnahmen während der Jobabarbeitung (2.B. Zugriff zur 
sog. SPOOL-Queue); 

- Aufgabenüberwachungsprozessor (XMON) für die dynamische Prioritä- 
tensteuerung; 

- Aktualisierungsprozessor (ACTU) für die Aktualisierung des SPOOL- 
Kataloges; 

- Prüfpunktprozessor (CKPT) für die Sicherung von Wiederanlaufinfor- 
mationen von SPOOL-Aktivitäten; 

- Ausgabeprozessor(en) (PRPU) für die Ausgabe der Jobergebnisse auf 
Drucker, Stanzer und (Drucklisten-)Magnetband; 
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- Kommandoprozessor (COMM) für die Umsetzung der Kommandosprache; 
- Konsolprozessor (CON) für die Unterstlitzung der Konsolbedienung; 


Das System SPOOL besitzt eine spezielle Überlagerungsorganisation, 
die es erlaubt, die Funktionen mit einem relativ geringen Hauptspel- 
cherbedarf zu realisieren (8.:4.5.). 


Zur Absicherung seiner Funktionen startet SPOÖL zwei (MFT) bzw. 

drei (MVT) Unteraufgaben in seinem Programmbereich. Darüber hinaus 
wird jeweils unmittelbar nach der Jobauswahl ein besonders modifi- 
ziertes Systemeingabeprogramm (OSRDR) initiiert. Im MFT arbeitet 

der OSRDR als S-transiente Aufgabe, im MVT wird er durch eine ge=- 
sonderte Unteraufgabe und den interpretierenden Teil des A5LD-Readers 
realisiert, 


Die zentrale Datei des Systems SPOOL ist die sogenannte SPOOL-Queue. 
Diese stark frequentierte Datei dient zur Aufbewahrung der Jobinfor- 
mationen (Jobstrom, -ausgaben, Steuerblöcke) und wird auf einem 

oder auf mehreren Nagnetplatten angelegt. 


3.2. Jobdurchlauf durch das_System SEOOL 


SPOOL kann Jobströme von Kartenlesern, sowie von Magnetplatten- und 
Hagnetbanddateien einlesen. Außerdem ist es Nutzerjobs oder interak- 
tiven Systemen Über die Komponente "Interner Reader" leicht möglich, 
Joba in die SPOOL-Queue zu delegieron,. Die in die SPOOL=-Queue gele- 
genen Jobs verbleiben dort in ihrer ursprünglichen Form bis zum En- 
de der Ausflihrphase, sodaß gef. Jobwiederanläufe (Restart oder 
Warmstart) möglich sind. 


Während der Jobeingabe werden die SPOOL-Steueranweinungen (5. 3.3.) 
analysiert, die für die Erzeugung der Jobinformationsliste notwendi- 
gen Angaben in einer Hilfsdatei abgespeichert und die Jobpriorität 
festgelegt. Nach der Jobeingabe wird mittels der SPOOL-Katalogdatei=- 
en die Verfügbarkeit der Ressourcen Rechenzeit, Papier und Datenträ- 
ger geprüft. Ein negatives Ergebnis führt zum Entfernen des Jobs aus 
dem Systen. 


Die von den akzeptierten Jobs benötigten Nagnetplattenarchivnummern 
werden in eine interne Tabelle (VOLTAB) eingetragen, wodurch eine 


datenträgerabhängige Jobauswahl und entsprechende Informationen in 
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der. Bedienerinformationsliste und in Displaykommandos ernöglicht 
werden. Außerdem wird vom System SPOOL untersucht, ob der Job ohne 
Bedieneraktivitäten verarbeitet werden kann oder nicht. 


Die Auswahl der Jobs zur Verarbeitung wird von SPOOL-Initiator-Pro- 
zessoren vorgenommen, die jeweils genau einem OS/ES-Initiator zuge- 
ordnet sind (Region bzw. Position). Die Auswahl erfolgt dabei in 
üblicher Weise über Jobklasse und Priorität, wobei die Betriebswei- 
se und das Ergebnis der internen Jobklassifizierung mit Einfluß 
nehmen. Der Initiator übergibt den ausgewählten Job dem OS/ES,-in- 
dem er einen Systemeingabeprogramn, dem sog. OSRDR, übergeben wird. 
Dieser überprüft die Syntax, modifiziert den Job für interne Zwecke 
und stellt ihn in der Systemkettendatei des OS/ES zur Abarbeitung 
bereit. 


Bevor die normale Abarbeitung des, Joba im OS/ES beginnt, wird mit- 
tels der SPOOL-Katalogdateien geprüft, ob die Verwendung der Magnet- 
plattendateien in zulässiger Weise erfolgt. Ein negatives Prüfergeb- 
nis führt zum Entfernen (automatisches CANCEL) des Jobs aus dem Sy- 
stem; andernfalls erfolgt die Freigabe (automatisches RELEASE) des 
Jobs, 


Während der Jobabarbeitung organisiert das System SPOOL die Eingabe 
der Eingabestromdateien und die Ausgabe der SYSOUT-Dateien gewisser 
(generierungsabhängig) Ausgabeklassen mit Hilfe der vorgenommenen, 
nur intern wirksamen Jobmodifikationen in solcher Weise, daß die 
Eingaben von der SPOOL-Queue und die Ausgaben in die SPOOL-Queue 
erfolgen. 


Nach Beendigung der Arbeit des Jobs werden dessen Jobnachrichten 
(SMB-Informationen) aus dem OS/ES in die SPOOL-Queue übernommen. 
Damit stehen alle Ausgabeinformationen des Jobs in der SPOOL-Queue 
zur Ausgabe bereit. 


Durch Ausgabeprozessoren werden sie auf Drucker, Stanzer oder kagnet- 
banü ausgegeben, Abbildung 2. 
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Abb. 2 Joblaufschema (stark vereinfacht) mit SPOOL 2.1 
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Das System SPOOL und die Nutzer (Problemanalytiker, Programmierer) 
kommunizieren durch 


- die vom Nutzer in den Jobs zu kodierenden SPOOL-Steueranweisun- 
gen, die neben Steuerparametern eine Auftragsbeschreibung (ähn- 
lich der Jobbegleitanweisung) enthalten; 

- die Jobausgaben, insbesondere durch die von SPCOL bereitgestellte. 
JOB-LOG, die Konsolnachrichten enthält, die den jeweiligen Job 
betreffen. 


Die SPOOL-Steueranweisungen beginnen mit der Zeichenfolge "/=", 
gefolgt von dem jeweiligen Kodewort. Auf Grund dessen wirken sie 
als Kommentaranweisungen, wenn SPOOL nicht aktiv ist, Im einzelnen 
gibt es folgende Anweisungen: 


- /»JOBPARM-Anweisung unter anderem mit Schätzwerten für Joblauf- 
zeit, Druckzeilenanzahl und benötigten SYSDA-Speicherplatz für 
Arbeitsdateien sowie mit Angaben zur Jobwiederholbarkeit, spe- 
ziellen Bedieneraktivitäten (WTOR) und Kopieanzahl der Jobliste; 

- /aSETUP-Anweisung mit Angabe der direkt angesprochenen Geräte, 
der Magnetdatenträger und der zu überschreibenden verfallsge- 
schützten Dateien einschließlich zusätzlicher Informationen wie 
Schreibringmontage bei Magnetbändern oder EOR=-Zeichen bei Loch- 
streifengeräten; 

- /#PRIORITY-Anweisung mit Festlegung der Jobpriorität; 

- /#MESSAGE-Anweisung mit Informationen, die zum Zeitpunkt der Job- 
eingabe an den Anlagenbediener übermittelt werden, 


Die von SPOOL ausgegebenen Jobausgabelisten weisen vor allen. fol- 
gende Besonderheiten auf: 


- Auf der Separatorseite des Jobs erscheinen zusätzlich die schon 
erwähnte JOBLOG sowie statistische Informationen (Laufzeit, Druck- 
zeilenanzahl, Drucklistertypen u.a.). 

- Die Jobnachrichten (JCL-Anweisungen usw.) erscheinen konzentriert 
am Anfarg der Jobliste unmittelbar nach der JOBLCG, 

- Nach den Jobnachrichten folgen die Ausgaben der Jobsystemausgabe- 
klasse, wobei Dateierde und Jobende durch entsprechende Nachrich- 
tenzeilen gekennzeichnet sind. 
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- Unterbrochene Joblisten bzw. Listen verschiedener Auszabeklassen 
werden mit einer neuen Scparatorseite begonnen, 


Die Kommandosprache des Systeus SFOOL zeichnet sich durch Binfach- 

heit, Kürze und durch die Verwendung von Listenkommandos, also das 

Verwerden eines Kommandos und die anschließende Ausführung dessel- 
ben für eine Gruppe von Jobs (mehrere Jobnummern), Geräten oder Da- 
tenträgern, aus. 


Kormandos und Nachrichten beginnen mit einem Währungszeichen ($). 
Der Kommandokode ist auf weitgehende Ähnlichkeit zu vergleichbaren 
OS/ES-Kommandos abgestimmt. 


Die SPOOL-Kommandos lassen sich in fünf Hauptgruppen einteilen; 


A. Systemkommandos 

B. Displaykommandos 

C. Jobkommandos 

D, Gerätekommandos 

E. Datenträgerkommandos. 


Viele dieser Kommandos können im Sinne einer Listenform auf mehrere 
Objekte gleichzeitig angewendet werden. Als Beispiel seien folgende 
Komrandos angeführt: 


S A J11-20,26-27 - Freigabe der Jobs mit der internen Jobnummer 
11, 12, ... bis 29, sowle 26 und 27. 


S S PRT1,RDR2,TPE2 - Starten der vorlibergehend gestoppten Geräte 
Drucker 1 (PRT1), 
Kartenleser 2 (RDR2) und 
Magnetbanddruckausgabe 2 (TPE2). 


5 M 111111,134,222222,137 
- logisches Verfügbarmachen (SPOOL-KNOUNT) der 
Platten mit der Archivnummer 111111 auf Ge- 
rät 134 und 222222 auf Gerät 137 (intern wird 
ein OS/ES-MOUNT wirksam), 
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Das Betriebssystem OS/ES (MFT/MVT) muß für die Arbeit von SPOOL 
durch eine:vollständige oder eine E/A-Generierung vorbereitet wer- 
den. Dabei müssen u.a. 


- eine gewisse Anzahl Pseudo-UR-Geräte für die Realisierung der 
SFOOL-Queue vorgesehen werden; 

- die Gerätegruppennamen A und INTRDR in System verfügbar sein; 

- der Typ 1 SPOOL-SYC eingeschlossen werden. 


Das so modifizierte Betriebssystem ist auch ohne SPOOL uneinge- 
schränkt arbeitsfähig. 
4.2. Generierung des Systems_SPOOL 


Das System SPOOL kann durch eine Vielzahl von Parametern variabel 
an die Gegebenheiten und Wünsche des Anwenderrechenzentrums ange- 
paßt werden. Die Generierung wird durch Systemprogrammierer mittels 
Auswahl der Generierungsparameter, z.B. Auswahl der Anzahl der 
SPOOL-Initiatoren, der zu unterstützenden SPOOL-Geräte, der Puffer, 
Jobklassen usw. oder aber Auswahl der Standardparameter für die 
JOBPARM-Anweisung oder Festlegen der Konsequenzen beim Übertreten 
der zulässigen Nutzungsbedingungen (Dateinutzung, Laufzeitüber- 
schreitung usw.) vorbereitet. Kriterien sind der gewünschte Funk- 
tionsumfang, der Umfang der zu unterstützenden Ressourcen und der 
Speicherbedarf. 


Für die Kontrollfunktionen von SPOOL ist ein Komplex von Katalogda- 
teien vorhanden, der aus 


- dem Zentralen Katalog (KAT), 

- dem Dateiverzeichnis (DSN), 

- der Auftragsdatei (ACC), 

- der Datenträgerdatei (VOL) und 

- Hilfsdateien 

besteht, die untereinander verkettet sind. 
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Für den Aufbau und die Pflege der Katalogdateien steht das Dienst- 
programz IEBSPOOL zur Verfügung /3/. 


Wie schon erwähnt arbeitet SPOOL als Aufgabe des Betriebssystems 
OS/ES. Während der Initiierungsphase werden zunächst von SPOOL im 
Betriebssystem temporäre Veränderungen vorgenommen, die die Arbeits- 
fähigkeit von SPOOL sichern (z.B. Modifikation der SVC-Tabelle).- 
Außerdem werden die Unteraufgaben und die CS/ES-Initiatoren gestar- 
tet und die SPOOL-Queue wird auf ihre Verwendbarkeit geprüft. Der 
Bediener hat die Wahl zwischen einem SPOOL-Warmstart und dem SFOOL- 
Kalt-/Formatstart. Beim Warmstart werden Jobs, die noch im System 
sind, zum Wiederanlauf geführt, den Ausgabeprozessoren zugeführt 
oder im normalen “Modus der prioritätsgesteuerten Abarbeitung unter- 
zogen. 


Wird dem Bediener der Rukestand des Systems ‚angezeigt, d.h. es ist 
kein Job mehr aktiv und kein Gerät ist in Arbeit, so kann er mit 
dem Kommando S PSPOOL die Beendigung der Arbeit des Systems SPOOL 
einleiten. Hierbei werden dann alle temporären Änderungen im OS/ES 
wieder rückgängig gemacht, sodaß das OS/ES wieder normal arbeits- 
fähig ist. 


Der iiauptspeicherbedarf des Systems SPOOL ist von der Auswahl der 
Generierungsparameter und damit im wesertlichen von der Hauptspei- 
chergröße und von der Gerätekonfiguration der Anlage abhängig. Für 
mittelgroße (512 K Bytes) und große Anlagen kann man unter der Steu- 
erprogramnkonfiguration MVT mit 60 bis 80 K Bytes rechnen, Für die 
Stouerprogrammkonfiguration EFT vermindert sich der Bedarf um etwa 

8 bis 10 K Bytes. Es sei darauf hingewiesen, daß zusätzliche Systen- 
eingabeprogramme und Systemausgabeprogramme nicht benötigt werden, 
sodaß sich bei Abzug von 40 K Bytes (residenter Teil des ASB-Readers 
und ein Systemausgabeprogramm) eine tatsächliche Speichermehrbela- 
stung von 20 bis 40 K Bytes bei Einsatz des Systems SPOOL ergibt. 


Der Wehrbedarf beim Steuerprogramm des OS/ES ist in Abhängigkeit von 
der'kenge der notwendigen Pseudogeräte auf ein bis zwei K Bytes zu 
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veranschlagen. 
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Gesellschaftliche und soziale Auswirkungen der EDV-Anwendung 


Die Analyse sozialer und gesellschaftlicher Wirkungen, die mit 
der Anwendung der EDV-Technologien verbunden sind, hat insbe- 
sondere in den letzten Jahren wachsende Beachtung gefunden. 
Nach anfänglicher Euphorie und bedingungsloser Zukunftsgläubig- 
keit ist in den westlichen Ländern der kritische und pessimi- 
stische Charakter der Technologiebewertung immer mehr in den 
Vordergrund gerückt. Viele sehen in der rasanten Technikent- 
wicklung der letzten Jahrzehnte die entscheidende Ursache für 
die immer sichtbarer werdenden gesellschaftlichen und sozialen 
Deformationen unserer Tage. 

So meint beispielsweise W. Steinnmüller: "Es droht heute nicht 
nur eine atomare und chemische Umweltverschmitzung, sondern 
ebenso die automationsunterstützte Denaturierung der psycho- 
sozialen Umwelt und Inwelt — nur mit dem Unterschied, daß in 
diesem Bereich die Entwicklung wesentlich schneller verlaufen 
wird als bei der Industrialisierung der körperlichen Arbeit. 
Deshalb handelt es sioh um eine Gegenwartsaufgabe, die nicht 
auf ungewisse Zukünfte vertagt werden darf." 

So etwa könnte man die kritische Grundrichtung der modernen 
bürgerlichen Wirkungsforschung in Kurzform zusammenfassen. 


Während in den kapitalistischen Ländern die Wirkungsforschung 
bereits eine reiative Breite erreicht hat, unterschiedliche 
theoretische Ausgangspunkte erkennbar sind und zu entsprechen- 
den Schulen und Richtungen geführt haben, stehen wir im Sozia- 
lismus noch ganz am Anfang einer wissenschaftlich begründeten 
Analyse der mittel- und langfristigen Auswirkungen bei der An- 
wendung moderner Technologien, wie sie insbesondere durch die 
Computertechnik und Mikroelektronik bereitgestellt werden. Zum 
Teil fehlt es noch Überhaupt an dem notwendigen Problembemußt- 
sein, weil man offensichtlich glaubt, daß sich unter soziali- 
stischen Produktionsbedingungen automatisch jeder wissenschaft- 
lich-technische Fortschritt zum Besten der Menschen auswirken 
nüsse. 
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Sicherlich gibt es für uns keinen Anlaß zu pessimistischer 
Sohwarzmalerei, wenn wir uns mit hohem Engagement der schnellen 
Entwicklung und Anwendung moderner Informationstechnologien zu- 
wenden. Dennoch sind die hierdurch bewirkten gesellschaftlichen 
und sozialen Wirkungen keineswegs problemlos. 

Bevor wir uns den einzelnen Wirkungen und ihrer Einschätzung zu- 
wenden, wobei insbesondere Prof. Fuchs-Kittowski zu den ver- 
schiedenen Strategien der Anwendung von Informationstechnologien 
im Hinblick auf die Ergebnisse moderner Wirkungsforschung noch 
sprechen wird, wollen wir im folgenden versuchen, uns Über ei- 
nige Grundfragen der Zielstellung und möglichen Ergebnisse einer 
narxistisch-leninistisch orientierten Wirkungsforschung ver- 
ständigen. 

Das ist deshalb so wichtig, weil durch die bürgerliche Wirkungs- 
forschung suggeriert wird, daß soziale und gesellschaftliche 
Auswirkungen der EDV-Anwendung prinzipiell negativ sind. 

Die Identifizierung von Wirkungen mit negativen Auswirkungen 

ist schon deshalb abzulehnen, weil eine solche Grumihaltung 
zwangsläufig zu einer konservativ-rcemantischen Kritik gegenwär- 
tiger Entwicklungsprozesse führen mıß, Die Wurzeln hierfür lie- 
gen unseres Erachtens in der unlösbaren Krisenhaftigkeit des 
kapitalistischen Gesellschaftssystems, wodurch jede Entwicklung 
als Verschärfung bestehender Widersprüche und folglich als sich 
beschleunigender Niedergang auch im theoretischen Denken reflek- 
tiert wird. 

Aus genau diesen Gründen können wir daher nicht unbesehen die 
sogenannten Erfahrungen der westlichen Länder bei der Einfüh- 
rung von EDV-Systemen Übernehmen. Gerade in der Wirkungsfor- 
schung und ihrer Einordnung, die mehr und mehr zu einem inte- 
grierenden Bestandteil der Informatik als Wissenschaftsdiszi- 
plin selbst geworden ist, zeigt sich der gesellschaftswissen- 
schaftliche Aspekt dieser neuen Wissenschaft. 


Jede Entwicklung -— das zeigt sich bereits in der Biologie - 
ist irreversibel, dh., daß eine Rückkehr zu früheren Ausgangs- 
punkten der Entwicklung nicht mehr möglich ist. Es gehört ge- 
wissermaßen zum Wesen der Entwicklung, daß sie in die Zukunft 
gerichtet ist. 
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Um so wichtiger ist es, Entscheidungen, die nachhaltige Auswir- 
kungen auf Entwicklungsprozesse haben, besonders gründlich zu 
überdenken. 


Ein weiterer Aspekt dieses Evolutionsverständnisses ist aber auch, 
die Ambivalenz jeglicher Art von Entwicklungsprozessen zu begrei- 
fen und in die Gestaltungsstrategien einzubeziehen. Ambivalenz 
heißt, daß Fortschritt nicht nur Verlängerung alles »isher Guten 
und Positiven und Verringerung alles bisher Schlechten und Nega- 
tiven ist und sein kann, sondern daß die objektiven Entwicklungs- 
zusammenhänge auch manches Liebgewordene und nicht unbedingt Ne- 
gative unter den Hammer bringen. 

Fortschritt ist ein objektiver Prozeß, der sich von den Wünschen 
der Menschen unterscheidet. Nur dort, wo das Gewünschte mit den 
objektiv Realisierbaren in Übereinstimmung zu bringen ist, wer- 
den zusätzliche Impulse eines subjektiven Engagements für die 
Durchsetzung des Neuen ausgelöst, während umgekehrt Diskrepanzen 
Zwischen dem wünschenswert Erscheinenden und dem objektiv Not- 
wendigen diese subjektiven Antriebe lähmt. In der marxistisch- 
leninistischen Ideologie widerspiegelt sich dieser Sachverhalt 

in dem Bemühen, die objektiven Erfordernisse gesellschaftlicher 
Entwicklung so überzeugend darzulegen, daß sie nicht nur verstan- 
den, sondern möglichst auch in persönliche Haltungen und Lebens- 
ziele umgesetzt werden. 


Die Beurteilung von Auswirkungen der EDV-Anwendung hängt aus den 
0.8. Gründen ganz wesentlich von den gesellschaftstheoretischen 
Grundpositionen ab, die der Wissenschaftler explizit oder inmpli- 
zit in die Wirkungsforschung der EDV einbrirgt. 


Fassen wir zurächst die beiden Ausgangspunkte unserer weiteren 
Überlegungen noch einmal zusamnen: 


1. Jede Entwicklung ist irreversibel. 
2. Jede Entwicklung ist ambivalent. 


Wenn man von Auswirkungen des Einsatzes der ETV-Technologien 
spricht, muß man natürlich präzisieren, welche Teilprozesse pri- 
zär am stärksten betroffen werden und welcher Zusammenhang zwi- 
schen direkten und indirekten Wirkungen bestekt. juch unter die- 
sem Blickwinkel ergibt sich die Notwendigkeit, ein wissenschaft- 
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lich begründetes Bild Über das Zusammenspiel von Teilprozessen 
in der Gesellschaft der Einordnung und Bewertung der Informa- 
tionstechnologien zugrunde zu legen. 

Anderenfalls kommt man Über rein phänomenologische .Beschreibun- 
gen nicht hinaus. Das ist meines Erachtens auch einer der Haupt- 
gründe, warun die bürgerliche Technologiekritik so überaus viel- 
fältig und buntscheckig ist. Neben naiven Gesellschaftsidyllen, 
die beschworen werden, findet man zuch recht abenteuerliche Be- 
Lauptungen Über angebliche Prinzipien und Gesetzmäßigkeiten, 
nach denen sich menschliches Leben in der Gesellschaft entfaltet. 
Je nach den Ausgangspunkten dieser meist implizit und intuitiv 
vorgetragenen Überzeugungen von Wesen der Gesellschaft unter- 
scheiden wir die mehr moralisierenden und appelierenden volun- 
taristischen Richtungen von den kausal analytischen und funkti- 
onalistisch beschreibenden. 

Gemeinsam ist all diesen Richtungen, daß aus den Tiefen des sog. 
menschlichen Wesens, das angeblich durch die technische Ent- 
wicklung der letzten Jahrhunderte deformiert wurde, die prin- 
zipielle Wirkungsweise der Informationstechnologien in Gegen- 
wart und Zukunft erklärt wird. Es soll jedoch auch richt uner- 
wähnt bleiben, daß hierbei auch immer deutlicher die wirklichen 
Ursachen beim Namen genannt werden, jedoch meist erst von den 
Verbrämingen befreit werden müssen, die ihnen schon deshalb an- 
haften, weil sie bürgerlich-salonfähig sein wollen und sein 
müssen. So erscheint die Technologieentwicklung und insbeson- 
dere der Einsatz moderner Informationstechnologien primär als 
ein generelles Menschheitsproblem und — erst davon abgeleitet - 
als ein konkretes gesellschaftlich bedirgtes Klassenproblen. 


Die marxistisch-leninistische Analyse dieser Sachverhalte geht 
genau umgekehrt davon aus, daß alle relevanten Faktoren und 
Probleme der Gesellschaftsentwicklung primär in ihrem Zusammen- 
hang mit den Interessen herrschender Klassen zu untersuchen 

sind uni erst nach Klärung und Herausarbeitung dieser Zusannen- 
hänge die allgemein menschlichen Implikationen moderner Technik 
und Technologie analysiert und eingeordnet werden können, Bei 
der Einschätzung, worauf die Technologien wirken, welche Ver- 
änderungen sie bewirken, sind folglich die Prozesse in den Nit- 
telpunkt zu stellen, die die. Gesellschaftsstruktur maßgeblich de- 
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terminieren. Das sind, aus marxistisch-leninistischer Sicht, in 
erster Linie der Arbeitsprozeß, die Organisationsstruktur, der 
Lebensprozeß und die Entfaltung und Entwicklung der Wesenskräfte 
des Menschen, wobei unter Nensch richt nur das Individuum, die 
Person, zu verstehen ist, wie die bürgerliche Ideologie Glauben 
machen will, sondern das Ensemble seiner wesentlichen Beziehungen 
und Verhältnisse. 


Sowohl historisch als auch vom Umfang der Analysen her gesehen, 
stehen die Wirkungen der Informationstechnologie auf den Ar- 
beitsprozeß im Mittelpunkt der Beurteilungen und Bewertungen. 
Durch die alleinige Konzentration auf den gesellschaftlichen Ar- 
beitsprozeß entstehen gleichzeitig jedoch Gefahren für Fehlin- 
terpretationen, weil man versucht ist, auch die nicht hierher 
gehörenden Wirkungen in diesem Aspekt einzuordnen und allein 
hieraus zu erklären. Der Arbeitsprozeß ist schon deshalb Aus- 
gangspunkt, weil er das direkte Einsatzgebiet der Informations- 
technologien ist, um Steigerungen der Arbeitsproduktivität und 
eine hohe Gesamteffektivität der Produktion zu erzielen, Die 
erste Schwierigkeit, die sich auch termlrologisch zeigt, ist die 
präzise Unterscheidung der gesellschaftlichen und sozialen 
Aspekte der untersuchten Wirkungen. Meist werden die gesell- 
schaftlichen und sozialen Wirkungen als identisch betrachtet. 
Aus der Sicht der marxistisch-leninistischen Gesellschaftstheo- 
rie empfiehlt es sich Jedoch, die Differenzierungsmöglichkeiten, 
die diese Termini bieten, auch in sinnvoller Weise zu nutzen. 
Da die Diskussionen einer solchen zweckmäßigen Unterscheidung 
noch in vollem Gange sind, soll an dieser Stelle nur gezeigt 
werden, in welcher Weise zwischen gesellschaftlich und sozial- 
unterschieden werden könnte, um die verschiedenen Wirkungsrich- 
tungen zu kennzeichnen: 


Unter sozialen Wirkungen soll im folgenden immer ein solcher 
wirkungsaspekt verstanden werden, der sich primär auf die be- 
telligten individuen bezieht, wobei allerdings unter Individuum 
nicht der einzelne Mensch schlechthin, sondern die durch die 
sosielen Bedizgungen seiner Existenz determinierte Persönlich- 
keitsstruktur gemeint ist. Sozial am und im Arbeitsprozeß sind 
also die auf den Menschen bezogenen Arbeitsbedingungen, die von 
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den elementaren Voraussetzungen, Überhaupt Arbeit zu haben, bis 
zu den konnlexenen Bedingungen reichen, welche Möglichkeiten 
der Arbeitsprozeß bietet, um menschliche Persönlichkeit zu ent- 
wickeln und zu entfalten. Hiermit ist der große Thenenkreis der 
viel diskutierten sogenannten Entfremdung oder der NMöglichkei- 
ten des Menschseins im Arbeitsprozeß unrissen. 


Der Finsatz der Informationstechnologien im Arbeitsprozeß ver- 
ändert in gravierender Weise sowohl den Inhalt als auch die 
Form menschlicher Tätigkeit. Durch die sich in großen Dimen- 
sionen vollziehenden Rationalisierungsprozesse werden ganze Be- 
reiche bisher menschlicher Tätigkeit durch die neue Technik 
selbst realisiert. Menschliche Tätigkeit wird also ersetzt und 
dadurch das gesamtgesellschaftliche Problem einer Neusetzung 
und Umprofilierung bisheriger menschlicher Tätigkeiten gestellt. 
Im Kapitalismus erfolgt dieser, Prozeß als Durohsetzung von Pro- 
fitinteressen und daher unmittelbarer und brutaler als unter 
sozialistischen Produktionsverhältnissen. Er zeigt sich vor 
allem darin, daß selbst bei leicht steigender Gesamtprodukti- 
vität die zunehmende Massenarbeitslosigkeit zu einem schein- 
bar unabwendbaren Begleitumstand der Expansion der EDV und 
Mikroelektronik geworden ist. Dieser ohne_ jegliche theoreti- 
sche Reflexionen greifbare Sachzusammenhang verführt sehr 
leicht zu der-Fehlinterpretation, daß die Informationstechno- 
logien selbst die unmittelbare und entscheidende Ursache für 
diese Vorgänge sind. 


Genau aus diesem Grunde ist es wichtig, nicht nur die auf der 
Oberfläche erscheinenden sozialen Wirkungen für das Wesen der 
Sache selbst zu nehmen, sondern die dahirter liegenden gesell- 
schaftlichen Gründe und Ursachen für diese Erscheinungen zu 
analysieren. Die gesellschaftlichen Grundstrukturen und Gruni- 
prozesse werden durch den Einsatz der Informationstechnologien 
nicht neu formiert oder determiniert, sondern mur in ihren 
Wirkungsmechanismus verstärkt und beschleunigt. Die Informa- 
tlonstechnologien schaffen keine prinzipiell neuen gesell- 
schaftlichen Probleme, sondern führen zur schnelleren Entfal- 
tung der in ihnen wurzelnden Entwicklungstendenzen. Inforna- 
tionstechnologien sinddaher Tendenzverstärker allgemeiner gesell- 
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schaftlicher Entwicklungsprozesse und nicht Ursachen für eine 
prinzipielle Veränderung. wmserer' Beurteilung des: Wesens der Ge- 
sellschaft: selbst. 


Die Unterscheidung zwischen sozial und gesellschaftlich wider- 
spiegelt sich bspw, auch in der Redeweise von einer Wirtschafts- 
und Sozialpolitik, die zwar eine Einheit bilden, aber eben nicht 
identisch sind. Die Wirtschaftspolitik dient der schnellen Ent- 
wicklung der Produktivkräfte unter Nutzung aller Ergebnisse der 
wissenschaftlioh-technischen Revolution, während die Sozialpc- 
litik die Art und Weise der Produktivitätsentwicklung deterni- 
niert. Da die Arbeitskraft die wichtigste Produktivkraft ist, 
alles was die Menschen tun durch ibren Kopf hindurch muß, kommt 
es eben darauf an, die Menschen selbst als Produzenten dazu zu 
befähigen, die notwendigen Wandlungsprozesse in der Produktion 
so zu realisieren, daß die Veränderung der Arbeits- und Lebens- 
bedingungen akzeptiert wird und sogar Triebkräfte für die Reali- 
sierung solcher Wandlungsprozesse freigesetzt werden. Die ge- 
sellschaftlichen Wirkungen der EDV-Anwendung bestehen also da- 
rin, daß dis bestehenden Gesellschaftsstrukturen sichtbarer aus- 
geprägt werden, das heißt konkret, daß sich im Kapitalismus der 
widersprüch zwischen Kapital und Arbeit weiter verschärft und im 
Sozialismus die prinzipiellen Vorzüge für eine gesamtgesell- 
schaftliche Organisation der Produktion immer umfassender durch- 
setzen. Diese Kennzeichnung bedeutet jedoch nicht, daß der Fin 
satz der Informationstechnologien automatisch zu solchen gesell- 
schaftlichen Wirkungen führt, weil ja die Umsetzung der mit den 
Informationstechnologlen verbundenen Erfordernisse immer wieder 
neu Entscheldungen Über Gestaltungsprinzipien und Einführungspro- 
zesse auf die Tagesordnung setzt. 


Wir hatten vorher zu zeigen versucht, daß jeder Entwicklungspro- 
zeß irreversibel und ambivalent ist. Das bedeutet, daß die Wir- 
kungen des Einsatzes von Informationstechnologien und der Ro- 
botertechnik in der materiellen Produktion zwangsläufig zu Ver- 
änderungen von Arbeitsinhalten führt, die nicht nur positiv be- 
wertet werden können, Es sind ja nicht mur die körperlich und 
psychisch unangenehmen Teile des menschlichen Arbeitsprozesses, 
die fundamentäl und irreversibel verändert werden, sondern es 
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ändern sich auch ‚Identifikationen der Menschen mit ihrer Quali- 
fikation und ihren Verantwortungsbereichen im Arbeitsprozeß, Es 
wäre naiv zu glauben, daß nach diesen Veränderungen nur schöpfe- 
rische und persönlichkeitsstimulierende Tätigkeiten übrig blei- 
ben. Tas Verhältnis von schöpferischen und nichtschöpferischen 
Tätigkeiten wird lediglich verschoben, nicht prinzipiell aufge- 
hoben. Das ist auch eir wesentlicher Grund dafür, daß die lieue- 
Tungen nicht nur emphatisch begrüßt, sondern zugleich auch ab- 
gelehnt werden, wenn die mit der Einführung der Informations- 
technologien verbundenen neuen Anforderungen äls weniger inte- 
ressant empfunden werden als der bisherige Arbeitsprozeß. Man 
muß daher jeweils die Gesamtheit der Bedingungen und Faktoren 
in Rechnung stellen, die vor und nach Einführung der Infor- 
mationstechnologien die Arbeits- und Lebensbedingungen bestimmen. 


Aus dem bisher Gesagtem geht hervor, daß die Analyse eires wei- 
teren Wirkungsaspekts notwendig wird, um die sich vollziehenden 
Tandlungsprozesse umfassend charakterisieren zu können. Ich 
meine hierbei die Organisationsstrukturen. Der Organisations- 
aspekt ist nicht nur ein Bestandteil des Arbeitsprozesses, son- 
dern durchzieht alle Formen des gesellschaftlichen Lebens, wie 
Politik, Kultur und Bildungswesen, Gesundheitswesen, Sport und 
erholung und viele andere Bereiche. 

Das Niveau einer gesellschaftlichen Fntwicklung zeigt sich nicht 
nur zm Stande von Wissenschaft und Technik und ökonomischen Pro- 
duktionsziffern, sondern auch an den damit verbundenen Struktu- 
ren unä Mechanismen der Organisation aller Arten von Lebenspro- 
zessen. Insbesondere die Informationstechnologien führten zu 
einer Hervorhebung und einer relativen Verselbständigung des Or- 
genisatiorsaspekts, weil insbesondere die Organisation selbst 
der unmittelbare Gegenstand dieser Technologien geworden ist. 
Das zeigt sich schon äußerlich darin, daß gut durchdachte Or- 
ganisationslösungen von ihrem konkreten Irhalt abhebbar ge- 
macht werden, um auf diese Weise automatisierte Informations- 
verarbeitungssysteme Übertragen und nachnutzen zu können. Es 
spielt unter diesem Gesichtspunkt eben keine Rolle, ob bspw. 

im Gesundheitswesen Medikamente bestellt, verwaltet und ver- 
teilt werden. müssen oder im rahren von Hardel und Versorgung 
Bestandhaltungs- und Belieferungsproblene für Warenhäuser zu 
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lösen sind. 

Das Hauptproblem der Organisation ist die Beherrschbarkeit von 
Planungs- und Koordinierungsprozessen. Jeder einzelne dieser in- 
einandergreifenden Teilprozesse ist durch eire lienge von Infor- 
mationen charakterisiert, Je mehr es gelingt, die Prozesse mög- 
lichst genau durch die für sie wesentlichen Informationen zu re- 
präsentieren, um so besser gelingt es, mit diesen Abbildern 
wirklicher Vorgänge informatorisch zu arbeiten, Organlisations- 
probleme zu analysieren und eingreifende Organisationsentschei- 
dungen zu treffen. Da nun die Computertechnik nur formalisierte 
Informationen zu verarbeiten gestattet, werden die Teilprozesse 
selbst vorwiegend durch Datensätze gekennzeichnet. Es wird hier- 
bei stillschweigend unterstellt, daß alle Organisatiorsphänonene 
auf diese Weise am zweckmäßigsten und effektivsten erfaßt werden 
können. Man spricht in diesem Zusammenhang auch von der Modellie- 
rung der durch die Organisation zu gestaltenden Phänomene. Auch 
der Mensch selbst als inhärentes Moment jeder Organisation wird 
hierbei leicht zu einem Datensatz. Viele bürgerliche Wirkungs- 
forscher beklagen daher den Substanzverlust, der als ambivalen- 
te Kehrseits des Organisationsfortschritts unweigerlich in Kauf 
zu nehmen ist. Der Computer wird nicht nur zu einem Hilfsmittel 
bei der Bewältigung von Organisationsproblemen, sondern er avan- 
ciert mehr und mehr zu einem Modell perfekter Organisation. Die 
Verkehrung einer Nittel/Zweck-Beziehung ist in der marxistischen 
Philosophie an vielen Entwicklungsproblemen anschaulich demon- 
striert worden. Die Informtionstechnologien sind gewissermaßen 
die moderne Form einer Reflexion Über Mittel und Zweck, bezogen 
auf die in großen Timensionen vor sich gehenden theoretischen 
und praktischen Veränderungen unserer Auffassungen Über Organi- 
sation und ihre Handhabung. 

Auch hier zeigt sich wieder die Ambivalenz jeder Art von Fort- 
schritt, hier bezogen auf den Organisationsaspekt. Meines Er- 
achtens haben sich die Gesellschaftswissenschaften unserer Tage 
noch Zu wenig mit diesen aktuellen Problemen beschäftigt und 
allgemein anerkannte Lösungen vorgelegt. \enn es wahr ist, daß 
Organisationsfortschritt mit Formalisierung der Organisations- 
strukturen zusammenhängt, dann darf wenigstens vermutet werden, 
daß die sich daraus ergebenden Konsequenzen nicht unproblema- 
tisch sind und weitere Analysen dringend erforderlich machen. In 
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der bürgerlichen Wirkungsforschung wird dieser Aspekt des 'Or-. 
ganisationsfortschritts mit wachsender Bürokratisierung gesell- 
schaftlicher Lebensprozesse in Zusammenhang gebracht und hieraus 
eine neue Quelle für menschliche Selbstentfremdung abgeleitet. 
Sicherlich ist dieser Kurzschluß nicht unbesehen zu akzeptieren, 
wie aber der Organisationsfortschritt umfassend aus marxistisch- 
leninistischer Sicht zu kennzeichnen wäre, ist das meines Er- 
achtens noch nicht voll gelöste Problem unserer Tage. 


Als einen weiteren Aspekt der Wirkung von Informationstechno- 
logien hatten wir den Lebensprozeß erwähnt. Der Lebensprozeß 
kennzeichnet die sogenannte Lebensweise. Gerade in den letzten 
Jahren nehnen die Forschungen Über die theoretische Bestimmung 
des Phänomens "Lebensweise!" und die Kennzeichnung ihrer Fakto- 
ren zu. Man spricht von der Lebensweise im Kapitalismus und im 
Sozialismus. Verbunden mit der Lebensweise ist das qualitative 
und quantitative Lebensniveau, gewissermaßen all das, was das 
Leben lebenswert macht. Ich will hier gar nicht erst versuchen, 
eine präzise Bestimmung des gesellschaftlichen Phänomens "Le- 
bensweise" zu geben. 

Für unsere Zweoke reicht eine relativ vage bleibende Skizzie- 
rung des Gebietes, zu dem jeder einen praktischen und anschau- 
lichen Zugang hat. = 

Wie verändert nun der Einsatz der Informationstechnologien un- 
sere Lebensweise? 

Hervorstechend ist hier vor allem der schnelle Ausbau der Kom- 
munikationsdienste. Die Kommunikation ist nicht nur ein Hilfs- 
mittel für die Koordinierung von Tätigkeiten, für die Lern-, 
Qualifizierungs- und Orientierungsprozesse in unserem Leben, 
sondern selbst eine menschliche Tätigkeit. Die Kommunikation ist 
geistige Vergegenständlichung von Ideen und Absichten, von Zie- 
len, Urteilen und Bewertungen. Sie ist primär das Aktionsfeld, 
in dem Subjekte aufeinander wirken und sich wechselseitig be- 
einflussen und verändern. Auch das menschliche Selbstverständ- 
nis bemutzt die kommunikativ gewordenen Bezeichnungen für Er- 
kenntnisse und Bewertungen. Die Kommunikation ist gewisser- 
maßen unsere unmittelbare Lebenssphäre. 

Gerade deshalb ist es so wichtig, die EDV-Rationalisierungen 
der Kommunikation richtig einzuordnen. Ihre Ambivalenz liegt in 
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der Gefahr, Kommunikation auf das maschinell Machbare zu redu- 
zieren und darüber hinaus als Fortschritt zu feiern. Auch die 
vorsichtigere Interpretation, nämlich die Lelstungsfähigkeit 

der Kommunikation durch den Computereinsatz zu erhöhen, ist 
schon deshalb nicht ausreichend, weil Inhalt und Funktion der 
menschlichen Kommunikation unanalysiert bleiben,. Kommunikation 
ist primär nicht -— wie in der EDV-Literatur meist zu lesen ist - 
Informationsaustausch, sondern Austausch von Meinungen, Gedäan- 
ken und Argumentationen. Damit wird das weite Feld der Beziehun- 
gen zwischen Informationen unä Werten berihrt. Neinungen sind’ 
gewertete Informstionen, "meine" Sicht der Sachverhalte. Bei der 
Argumentation fungieren die Werte sogar als Ausgangspunkt und 
Ziel der Kettung von aussagen. Genauso unäabweisbar ist die \ert- 
problenatik für das Verständnis von Entscheidungsprozessen, die 
man eben nur dann mit ruhigem Gewissen einem Computer überant- 
worten kann, wenn man zuvor den Menschen zu einem verdinglich- 
ten Sachverhalt gemacht hat. Hier kann man geradezu mit Händen 
sreifen, wie die Grundtendenz der kapitalistischen Deforrierung 
des Nenschen zu einem seelenlosen Rädchen im Profitrwechanismus 
durch den Computer praktisch und durch eine entsprechend orien- 
tierte computer-science theoretisch verstärkt wird und gewisser- 
maßen nachträglich eine als "wissenschaftlich" deklarierte Be- 
grünäung erfährt. 


An der Kommunikations-TProblematik scheiden sich meines Erachtens 
die Geister, die die modernen Informationstechnologien herauf- 
beschworen haben, viel fundamentaler als an anderen EDV-Anwen- 
dungen und ihren Auswirkungen. Gerade auf Giesen Gebiet muß ge- 
dankenlosen Vereinfächungen viel energischer widersprochen wer- 
den, um Cie Computer in die Schranken zu verweisen, damit die 
enschen sich ihrer eigenen Rolle besser bemußt werden können, 
Gerit ein sinnvoller Gebrauch der neuen Technik möglich wird, 
Ich möchte daher Gas Wesen der menschlichen Kommunikation roch 
einmal kurz umreißen, damit es durch tbersteigerte Computer- 
Euphorie nicht ir Vergessenheit gerät: 


Es genügt nicht, beim Sender und Empfänger "ein gemeirsames 
Alphabet" und eine Übereinstimmung in den Wortbedeutungen (Be- 
eriffen) zu fordern, um die Kommunikation von Meinungen und 
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Gedanken erfolgreich zu gestalten. Tie Modelle, die die kommuni- 
zierenden Partner voneinander haben, sind Sübjektmodelle, Anti- 

zipationen der Persönlichkeitsstruktur, an die die Ideen gerich- 
tet sind, an der eine Wirkung erzielt werden soll. 


In der Komrunikation treten die Menschen daker einander als un- 
verwechselbare Individuen gegenüber, nicht austauschbar. Daher 
nimmt diese Kommunikation selbst einen individuellen Zug an und 
ist im engeren Sinne des Wortes zwischenmenschlich. Sie dient 
entweder vorwiegend der Einflußnahme auf die Ideen des anderen 
oder ist eine Offenbarung der eigenen Ideen in der Hoffnung, daß 
der andere helfen möge, nicht mehr stimmige Informationserzeu- 
gungsprozesse aus seiner Sicht zu analysieren und damit Hilfe zu 
geben, 


Ein wesentlicher Grundzug der Ideen-Kommunikation ist daher das 
möglichst komplexe Verständnis für den anderen, die eirfühlsane 
Teilnahme an seiner Subjektivität. Dieses Verständnis ist um’ so 
tiefgreifender und umfassender, je ähnlicher die vom anderen 
empfundenen Konflikte und Interpretationen den eigenen Erfahrun- 
gen sind, die uns geprägt haben, de mehr also derartige Situ-. 
ationen durchlebt wurden, 


Es sind nicht die Kenntnisse und Erkenntnisse selbst, die bei 
einer Ideen-Kommunikation ausgetauscht werden, obwohl davon vor- 
dergriindig die Rede ist, sondern die Sicht der Problenzusan- 
menhänge, aus der diese Erkenntnisse erwachsen, 


Ein durch viele praktische Beispiele belegbares Phänonen der 
Ideen-Kommunikation ist der Sachverhalt, daß mitunter mit we- 
nigen Worten sehr viel oder umgekehrt mit sehr viel Worten sehr 
wenig Ideen Übertragen werden können. Die Informationsbedeutun- 
gen, die Münzen, in denen wir zahlen, sind nur aktivierende Terk- 
zeuge für Eingriffe an den fremden Ideen, Sie sind nur Mittel, 
nicht Zweck der Kommunikation. 


Während in der objektiven welt die Kräfte die gegenseitigen Be- 
einflussungen realisieren und einen Gesamtzusammehhang der Din- 
ge und Erscheinungen konstituieren, stehen dem Subjekt für sei- 
ne Wirkungen auf andere Subjekte nur die Wöglichkeiten der kom- 
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munikativen Einflußnahme auf deren Struktur zur Verfügung. 
Kommunikation ist gewissermaßen das Kraftfeld, in dem sich Sub- 
jekte verändern, in dem sie existieren und sich bewähren. 


Die Veränderung der technischen Grundlagen und technischen Mög- 
lichkeiten für die kommunikative Erreichbarkeit verändert nach- 
haltig die Lebensbedingungen der Menschen. In erster Linie ist 
hier an die neue Generation von Massenmedien zu denken. Die Aus- 
wirkungen auf die Persönlichkeitsentwicklung sind keineswegs 
restlos aufgeklärt. Es gibt viele Langzeitforschungen, die sich 
diesem Problemkreis zugewandt haben. 


Die Aufgabe, vor der wir theoretisch und praktisch stehen, ist 
die Verbindung von wachsender Objektivierung einer immer größer 
werdenden Zahl von gesellschaftlichen Prozessen durch den Ein- 
satz der Informationstechnologie mit einer schritthaltenden 
Subjektivierung, d.h. Subjektwerdung des Menschen. Die Entfal- 
tung der Schöpferkräfte des Menschen ist und bleibt das Be- 
wertungsmaß für den Fortschritt. Computer sind Vergegenständ- 
lichungen dieser Kräfte, nicht aber sie selbst. Sie müssen für 
uns handhabbar gemacht werden, nicht wir für sie. Der Mensch 
ist niemals ein Störfaktor perfekter Organisation, Sorgen wir 
gemeinsam dafür, daß der Computer kein Störfaktor für uns und 
unsere Entwicklung wird! 


Literaturhinweise: 

W. Steinmüller "Datenverkehrsrecht oder Informationelles 
Selbstbestimmungsrecht des Bürgers? — Tendenzen und Probleme 
der Informationsautomation" aus "Mensch und Computer": Zur 
Eontroverse der 5ökonom. u. gesellschaftl. Auswirkungen der EDV/ 
hrsg. von Hans Robert Hansen ... München, Wien: Oldenbourg, 
1979 


Verfasser: 
Prof. Dr. Bodo Wenzlaff 
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Pilgrim, Jürgen 


Der EDV-Benutzer - Versuch einer Beschreibung und Definition 


Zunehmend muß sich der Mensch auseinandersetzen mit verschie- 
denen Formen der elektronischen Rechentechnik: mit Rechnern, 
Terminals, Mikroprozessoren und Bürocomputern.. Dabei wird er- 
wartet, daß er diese Technik und entsprechende Nutzungstech- 
nologien sinnvoll beherrscht. Nur dann können die Computer- 
systeme ihre volle Effizienz erreichen. 

Der sich verstärkende Übergangzur dezentralisierten Datenver- 
arbeitung - ein Ende dieser Entwicklung ist derzeitig über- 
haupt nicht zu erkennen - forciert diese Aussagen. 

Die bisherige Arbeitstätigkeit von Menschen, ihr Inhalt, wer- 
den somit durch Informat-ionstechnologien verändert oder be- 
reichert oder sogar verdrängt. Darin liegt die eigentliche 
Problematik der EDV mit ihrem Grundcharakter als massiv ar- 
beitseinsparende Technologie. 

Vom Menschen als Benutzer werden erwartet: Verständnis, Anpas- 
sung und Engagement gegenüber den Informationstechnologien, 
wobei die bisherige Entwicklüng ‚der Computerisierung in den 
kapitalistischen Ländern zeigt, daß das außerordentlich schwie- 
rig und bezüglich sozialer Auswirkungen in gesellschaftlichen 
Dimensionen dort kaum beherrschbar ist. 

Aufgrund der zunehmenden Automatisierung ergibt sich auch für 
uns die Notwendigkeit, sich mit derartigen Fragen zu beschäf- 
tigen, um unerwünschte soziale. Auswirkungen und Hemmnisse zu 
vermeiden. 

1. Bisherige Positionen des Benutzers in der EDV 


Es lassen sich in der bisherigen Entwicklung der EDV unter- 
schiedliche Positionen des EDV-Benutzers feststellen: 
1.Etappe (um 1955 bis Mitte der 60°er Jahre): 
Überkang vom reinen Computing auch zur Zeichenkettenverar- 
beitung und Time-Shering-Systemen. Entwicklung neuer Pro- 
grammiersprachen (FORTRAN 1954, ALGCL 1969). Sie führen zu: 
- der Erweiterung der EDV vom reinen Hardwareverständnis 
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zum Software-Hardware-Komplex, insbesondere durch Einbe- 
ziehung von Software und Information (Datenbanken) 

- ersten Problemen der Wensch-Rechnereffektivität und daraus 
resultierendem Interesse an vergleichbaren Experimenten 
und Studiän(vgl. SACKMAN / 1 /) 

2.Etappe (Mitte der 60°er Jahre bis um 1975): 
Enorme technische Weiterentwicklung (Verkleinerung, Verbilli- 
gung, Massenhaftigkeit, Dezentralisierung), z.B. 1965: IBM 
360, PDP 8; 1966: Diesplayterminal; 1971: ARPA - Rechnernetz, 
ISI-Mikroprozessoren. 
Es entsteht eine wachsende Akzentuierung von Kensch-Naschine- 
Systemen, und ein vom Computer determiniertes Denken entwik- 
kelt sich, das alles für formalisierbar hält( vgl. NEWELL und 
SINON / 2 /. 
Es werden realisiert ergonomische Untersuchungen von IMS, da 
da der Mensch als Benutzer zum begrenzenden Faktor wird 
(Adaptionszwang!), wobei aber allgemein die Nutzeruntersu- 
chungen nicht Schritt halten (NICKERSON / 3 /). 

3.Etappe ( seit der 1.Hälfte der 70’°er Jahre): : 
Multidimensionalität des Leistungsvermögens und Anwendung der 
EDV als Informationstechnologie. 
Sie führen zur zunehmenden Kritik infolge wachsender sozialer 
Auswirkungen, verbunden mit der Einführung der Mikroelektro- 
nik. Kritiker sprechen vom Neotaylorismus (vgl. u.a. 
WEIZENBAUM / 4 /). Die Abwehr negativer sozialer Auswirkungen 
erscheint als wichtigste Motivation in den kapitalistischen 
Ländern. 
Perallel zu dieser Entwicklung entsteht die sogenannte 
Wirkungsforschung, vor allem in den skandinav-ischen Ländern 
(vgl. BJÜRN-ANDERSEN und BORUM / 5 /), gekennzeichnet durch 
die Einbeziehung des Nutzers in die Systemauffassung und zwar 
zunächst als passive Komponente und Jetzt als Mitgestalter. 


Es wird somit der Mensch zunehmend als EDV-Benutzer interessant 

- eine arbeitsmäßige Funktion und Rolle, die er Überwiegend als 
Nicht-EDV-Fachnmann ausübt, und die künftig auch in der priva- 

ten Sphäre wahrzunehmen ist, 

Damit werden zwei Gesichtspunkte gravierend: 
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- die zeitlich unterschiedlich determinierte und ausgeübte Rol- 
le als EDV-Benutzer neben einer Vielzahl anderer Rollenfunk- 
tionen, 

- die Ausübung dieser Rolle als Nichtfachmann der EDV, 


2. Zur bisherigen Beschreibung des EDV-Benutzers 


Analysiert man den EDV-Benutzer im bisherigen EDV-Schrifttun, 
so zeigt es sich, daß eine ausreichende, umfassende Definition 
über ihn nicht existiert. Es gibt eine Vielzahl von fragmenta- 
rischen Ansätzen, 2.B. bei MARTIN / 6 /, U.E.FISCHER / 7 /, und 
Begriffen wie aktive und passive Nutzer, first-time Nutzer und 
first-come Nutzer, Problemlöser u.a., die aber mehr die ver- 
nachlässigte Rolle des Menschen als Benutzer in der Informa- 
tlionstechnologie betonen als eine erschöpfende Auskunft ver- 
mitteln. Schon 1979 sprach H.SACKMAN vog vergessenen Menschen 
in der EDV / ı /. 
In der Fachliteratur der kapitalistischen Länder nimmt seit: 
einigen Jahren der EDV-Benutzer eine wachsende, signifikante 
Position ein (vgl. auch: MUMFORD und SACKMAN / 8 /; HANSEN, 
SCHRÖDER. und WEIHE / 9 /), wobei an ihm, resultierend aus den 
gesellschaftlich unkontrollierten sozialen Auswirkungen, Zu- 
nehmend die "Negativität" der Computerisierung betont wird - 
ohne die eigentlichen gesellschaftlichen Hintergründe für diese 
Phänomene explizit zu benennen, 
Demgegenüber soll es unser Anliegen sein, den EDV-Benutzer un- 
ter dem Gesichtspunkt der Produktivitäts- und Kreativitätsver- 
besserung für die EDV-Nutzung und damit für den zugrundelie- 
genden Arbeitsprozeß zu untersuchen, und somit den positiven 
Beitrag der EDV zur Entwicklüng der Produktivkräfte aber auch 
des menschlichen Denkens in Abhängigkeit von der gesellschaft- 
lichen Determiniertheit hervorzuheben und zu forcieren. 
Derzeitig lassen sich mindestens 6 unterschiedliche Positionen 
bei der Bestimmung oder Beschreibung des EDV-Benutzers nach- 
weisen, denen unterschiedliche Standpunkte aber auch verschie- 
dene wissenschaftliche Disziplinen zugrundeliegen: 
1. Die Auffassung des EDV-Benutzers als Nensch, als besonderer 
Verhaltenstyp, charakterisiert durch bestimmte psychische 
Eigenschaften - und damit als ein Begriff der Psychologie 
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(WEINBERG /10/ spricht z.B.-vom abgesonderten Typ des Pro- 
grammierers; vgl. auch die interessante Arbeit von 
SHNEIDERMAN / 11 /). 

2.Die Auffassung des EDV-Benutzers als eine Identifikations- 
nummer in einer Warteschlange von Rechenaufträgen, d.h., als 
Element von bedienungstheoretischen Modellansätzen des Job- 
durchsatzes (vgl. u.a. BOIES / 12 /). 

3.Die Aufassung des EDV-Benutzers als Element der Funktions- 
einheit Mensch-Maschine-Systen, d.h., als Teilleistungskon- 
ponente eines Gesamtsystems (vgl. Mc CORMICK / 13 /), d.h., 
vorwiegend als kybernetische Interpretation unter informa- 
tioneller Betonung (Kommunikationsproblem!), oder auch unter 
arbeitswissenschaftlichen Gesichtspunkten (NEUMANN und 
TIME / 14 /). 

A,.Die Auffassung des EDV-Benutzers ‘als Element einer Gesant- 
heit, d.h., einer Gruppe mit bestimmten, übereinstimmenden 
Merkmalen wie z.B. der medizinische EDV-Benutzer, der Systen- 
programmierer usw.. Biese Auffassung ist weit verbreitet 
und dient meist der Systematisierung von Nutzerkategorien 
oder Nutzungaanforderungen, 

5.Die Auffassung des EDV-Benutzers als Element des Nutzer- 
systens, d.h., nur in Verbindung mit seiner EDV-Aufgabe und 
demit aus der Sicht des Rechnerbetreibers und -entwicklers 
(vgl. PILGRIM / 15 / und angenähert bei EASON / 16 /). 

6.Die Auffassung des -EDV-Bönutzers als Initiator und Träger 
der Arbeitstätigkelt "EDV-Nutzung", d.h., als eine Kategorie 
der Informatik, die von uns vertreten wird. 


3. Das Nutzersystem in der EDV 


Unter Nutzersystem wird von uns verstanden das funktionelle 
Zusammenwirken des EDV-Benutzers mit seiner arbeitsmäßigen 
Ungebung in bezug auf die Inanspruchnahme von EDV-Leistungen 
bei der Bearbeitung seiner EDV-Aufgabe. Dabei besteht ein 
Nutzersystem (N,) mindestens aus folgenden Elementen, die 
diese Repräsentanz widersplegeln? 
- EDV-Benutzeraktivitäten (B,)» d.h., der arbeitsmäßig eigene 
Anteil des Benutzers an der Realisierung der EDV-Aufgabe 
(z.B. nur die Aufgabe vorgeben als Auftrag oders nur Ergeb- 
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nisse berechnen und auswerten oder: gesamte Programmentwick- 
lung Selbst durchführen ), 

- die Motivation und Einstellung zur EDV-Nutzung (als rekursive 
Grössen aus dem Gruppeneinfluß, der insbesondere als Gruppen- 
ziel die Problemlösung und Aicht die EDV-Aufgabe verfolgt) (Bu), 

- die .EDV-Qualifikation des EDV-Bönutzers (persönliche Erfah- 
rungen, Übungen und Lehrgänge), ( Ba), 

- das Niveau der EDV-Aufgabe als Bearbeitungsprozeß, (E,), 

- die rechentechnischen Anforderungen der EDV-Aufgabe zwecks 
ihrer Bearbeitung und Lösung. (E,). 

Es ergibt sich dann folgendes Strukturmodell eines Nutzersystems 


(Abb. 1 ): 
u , 
_0- 1I2,-0--0— : 
ı / Ei 
EDV -Ounlifikahen 


rechentcchn. Anfard. 
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Es zeigt sich eine bestimmte Polarität in diesem Modell in be- 
zug auf 
- Motivation und Einstellung. zur EDV und 
- rechentechnische Anforderungen, 
die gleichzeitig als N, - Elemente auch die Schnittstellen zur 
Umgebung beschreiben. Sie sollten deshalb besonders das Objekt 
von Nutzeruntersuchungen bilden. 
Aus der Sicht eines Rechenzentrums als Betreiber von Rechen- 
technik hat ein Nutzersystem den Charakter eines Systems, das 
sich laufend modifiziert 
- im Ergebnis von Veränderungen der Einflußgrössen einschließ- 
lich der Elemente selbst, 
- in Anpassungen an die EDV-Nutzung und .daraus resultierender 
Anforderungen. 
Daraus ergibt sich die Notwendigkeit der möglichst quantitati- 
ven Bestimmung des Zustandes als auch der Entwicklung eines 
Nutzersystens. Der Zustand eines N, 1äßt sich durch einen Vek- 
tor beschreiben, wenn für den Index i ein aktueller Wert für 
die Elementmerkmale oder Indikatoren von B, eingesetzt werden 
kenn. Die Merkmale erhalten damit bewertet den Charakter von 
Variablen, 
Beispiel: 
Rechentechnische Anforderungen 
Indikator: 
Kontinuität der Inanspruch- Index i (i = 1...5) 
nahme des Rechners 


- kontinuierlich, regelmäßig 


- kontinuierlich, mit Unter- 
brechungen 


- häufig 
- gelten, unregelmäßig 
- sehr selten 


[5 


PD 


weitere Indikatoren: 
2.B. Verweilzeit des Rechenauftrages, 
benötigte Dateien (Umfang). 
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Aus der Sicht des Betreibers und Entwicklers von elektroni- 
scher Rechentechnik wird dann der Zustand von N, identisch mit 


einem bestimmten, erreichten Kompliziertheitsgrad von N, ‚, den 
wir mit Ky bezeichnen, 


Es gilt: 
N, = ( B,» By Boa Eis Er ) 
B, = 2: bi 


By = Cs di» e 


n’aırt b; +c, + dy te; et 

Mit dieser Ableitung wird ersichtlich, daß die Entwicklung ei- 
nes N, aufgefaßt wird als Entwicklung seiner Kompliziertheit 
Ry ‚„ die aber immer bewertet wird vom Standpunkt des Betrei- 
bers oder Entwicklers. Damit zeigt sich die Kompliziertheit 
KR] ale Prozeß im ZeitabschnittA, ‚ den man als "Lebensdauer" 
eines N, bezeichnen kann. Das bedeutet, daß ein Benutzer mit 
seiner EDV-Aufgabe und ihrem Bearbeitungsprozeß mit einer va- 
riablen Kompliziertheit K für einen bestimmten, oft vorher 
nicht abschätzbaren Seitabschnitt für ein Rechenzentrum oder 
einen Computer als sogenanntes Nutzersystem existent und nach- 
weisbar ist. 

Die Entwicklung von N, und damit seiner Kompliziertheit ist 
als stochastischer Prozeß zu bewerten, wobei die Elemente von 
N, einer unterschiedlichen Dynamik unterliegen (Abb, 2 ). 

Der grafische Ansatz in Abb, 2 ist grob und repräsentiert nur 
die Tendenz. £n der Praxis zeigt die Kompliziertheit der ein- 
Zelnen Elemente eine nichtlineare Entwicklung, die zusätzlich 
noch durch einen diskontinuierlichen Verlauf oder Wirksankeit 
der Elemente und ihrer Indikatoren beeinflußt wird. 

So bleibt der Zuwachs an Kompliziertheit bei Bu (Benutzer- 
aktivitäten) sehr.gering bzw. gleich Null: der Benutzer rea- 
lisiert bei einer konkreten EDV-Aufgabe allgemein das gleiche 
Niveau an Aktivitäten . By (Motivation und Einstellung) ver- 
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Ab. Entwicklung der Elemente ven N, 


ändert sich nur langsam aber dann sprunghaft im Sinne einer 
Stufenfunktion. Motivation und Einstellung, basierend auf ei- 
nem überwiegend problemorientierten, fachlich und sozial be- 
dingten Einstellungshintergrund sind in kurzen Zeiträumen 
kaum zu verändern (Ausnahmen: langzeitige Nutzersysteme in 
Gestalt von Programmsystemen!). 

Der Kompliziertheitszuwachs bei der EDV-Aufgabe (E,3 ist ty- 
pisch für langzeitige oder langlebige Nutzersysteme im Be- 
reich der Forschung. In Abhängigkeit vom problemorientierten 
Erkenntniszuwachs entwickeln sich aus kleinen Computerpro- 
gramnen über wiederholte Korrekturen und Verbesserungen große 
und komplizierte Programmsysteme, oft mit einer Vielzahl von 
Unterprogramnen, 

Am stärksten dürften sich die rechentechnischen Anforderungen 
( Eg ) entwickeln - in Abhängigkeit vom Niveau der Entwick- 
lung der EDV-Aufgabe (E,) und vom Zuwachs an EDV-Kenntnissen 
und -Brfahrungen. Gerade bei Erstnutzern ist dieser Zuwachs 
besonders ausgeprägt, wobei häufig nutzerseitige Überforde- 
rungen bezüglich rechentechnischer Anforderungen vorherr- 
schen. 

Die Entwicklung eines Nutzersystens wird von verschiedenen 
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Ursachen bestimnt: 


1. 
2. 


3 


Es existiert eine unterschiedliche Entwicklungsintensität 


-und -tendenz der Elemente von N,* 


Die Elemente von N, partizipieren zeitlich nicht parallel 
an der Entwicklung der Kompliziertheit K, von N,» 

Änderung der Aufwandsrelation Entwicklung : Anwendung (Rou- 
tinenutzung), 2.B. bei einer Programmentwicklung. In Abhän- 
gigkeit vom Bearbeitungsfortschritt erhöht sich allgemein 
der Routineanteil (vgl. Abb. 3 ). 

Unkontinuierliche Arbeiten an der Erogrammentwicklung, d.h., 
Realisierung von EDV-fremden Wätigkeiten neben der EDV-Auf- 
gabe und somit Vorhandensein sogenannter Totzeiten für die 
EDV-Nutzung. / 


Abb. 3 zeigt eine modellartige Vorstellung der prinzipiellen 
Entwicklung eines N,* Typisch ist dabei die Verringerung des 
Zuwachses von Ky mit wachsendem t . 


&, En 
N 4 
2 2 Proyrammeati, kl 
Pi, = Edi Anwendung (Restne) 
Ar = Lebensdaser unes A 


Abs. 3 Entwickleng Luc h, ( vereinfacht) 
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Alle 6 0.8. Auffassungen über den EDV-Benutzer, mit Ausnahme 
der letzten,sind partiell und gezielt anwendbar, beschreiben 
aber nicht umfassend den EDV-Benutzer, 
Nachfolgend soll die letztgenannte Auffassung betrachtet wer- 
den, in der der EDV-Benutzer als Träger der EDV-Nutzung aber 
auch als soziale Komponente der Informationstechnologie ver- 
standen wird. Mit dieser Interpretation. erhält der EDV-Benu- 
tzer den Charakter einer " 3.Dimension" in der Informatik - 
neben der Hardware ‚und Software] 

Es wird dann erforderlich, 2 Schwerpunkte vordergründig zu j 

untersuchen: ” 

1. Die Analyse der arbeitsmäßigen Einbindung des EDV-Benutzers 
in die EDV, d.h., die Untersuchung der Arbeitstätigkeit 
"EDV-Nutzung". 

2. Die Analyse der arbeitsmäßigen Umgebung des Benutzers, d.h., 
die soziale Wechselwirkung während der EDV-Nutzung und 
mittels der Informationstechnologie, 


4, Die EDV-Nutzung als Arbeitstätigkeit 


Der EDV-Nutzung als Arbeitstätigkeit liegen allgemein folgende 
Aktivitätengruppen zugrunde (Abb. 4 ): 


Benufzer! Interakhenss häre Cornpüder ‚Behreiber, 
u u 2 _(EDvsyshem ) 


( 1 Kemmonkubons- 8 
I | 


| 
Brig] I 


1 Stewerungs akbindeden] 
| age). 1 


| 


LEDER] Mirile ae Arbarh Ich she „Edi hereuag rer facht) 


81 


1. Arbeitsaktivitäten 
als eigentliche Tätigkeiten eines be- 
stimmten Trägers, die somit immer träger- 
bezogen und die Erfüllung der. EDV-Aufgabe 
unmittelbar verwirklichen, d.h., final- 
orientiert am Endprodukt (z.B. Rechen- 
programm) sind (Beispiel: Schreiben von 
Programmanweisungen). 
2.Steuerungsaktivitäten 
zwecks Steuerung des Ablaufs der EDV- 
Nutzung. Sieizeigen sich als Resultat von 
Kommunikationsaktivitäten und bewirken 
gezielte Eingriffe in Handlungsabläufe 
(Prozesse) (Beispiel: Zusammenstellen 
von Jobsteuerkarten für einen Rechenauf- 
trag. 
3. Kommunikationsaktivitäten 
mit dem Ziel einer Informierung des 
Veranlassers bzw. des Empfängers u.a. für 
Steuerungsprozesse (bzw. -aktivitäten) 
Beispiel: Fehlermitteilungen durch das 


Systen). 
Man kann nun- folgende :Beziehung herstellen: 
Arbeitstätigkeit EDV-Nutzung ( Arzpy) K,rst:D, 
£ 03 8 


= Arg + Kog + Stg + Ar + Kon + Stpj Kr de 
Alle 3 Arten von Aktivitäten partizipieren träger- und un- 
fangsmäßig, inhaltlich und zeitlich unterschiedlich in Jeder 
EDV-Nutzung. Das betont in Abhängigkeit vom Typ der EDV-Nu- 
tzung (z.B. Datenerfassung oder Programmentwicklung) die mög- 
liche und oft tatsächliche Individualität von EDV-Nutzungen, 
die dabei vor allem vom EDV-Benutzer bestimmt und getragen 
wird. 
Hier liegt die eigentliche Problematik der Dialektik von 
Flexibilität und Starrheit im EDV-Einsatz, die sich in einem 
Pro oder Contra der EDV-Nutzungsfreundlichkeit in der praxis 
niederschlägt, über Akzeptanz oder Ablehnung von Informations- 
systemen durch: den Benutzer sichtbar wird. Hier wird über die 
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tatsächliche Effektivität der EDV-Anwendung entschieden. 

Andererseits befinden sich auf diesem Gebiet auch die Reserven 

bezüglich Aufwertung des EDV-Benutzers und seines Einsatzes als 

Produktivitäts- und Kreativitätsfaktor. 

Kommunikations- und Steuerungssaktivitäten charakterisieren die 

eigentliche und notwendige Wechselwirkung des Benutzers nit 

der EDV-bezogenen arbeitsmäßigen Umgebung, 2.B. dem Computer; 
sie zeigen externes Verhälten des Benutzers an. Insofern wird 
die 0o.g. Individualität oder auch vorhandene Isolierung des 

Menschen bei einer Programmentwicklung durch diese Aktivitäten- 

gruppen, insbesondere durch Kommunikationsbeziehungen, durch- 

brochen und kann beeinflußt werden - ein signifikantes Ziel 
von Gestaltungsstrategien für den Entwickler und Betreiber 
von Computersystemen! 

Diese Aussagen bezüglich der 3 o.g. Aktivitätenarten des EDV- 

Benutzers sind gravierend, da sie bestimmen oder zeigen: 

- die Ausbildung eines (tatsächlichen und damit realen) Kom- 
munikationsniveaus, 

- die Kompliziertheit einer wirksamen Einflußnahme auf die 
Kommunikationsbeziehungen in der EDV-Nutzung, 

- Kommunikation und Steuerung als Prozesse (u.a. Benutzerakti- 
vitäten), die nicht unmittelbar (!) an eine interaktive 
Rechnernutzung im Dialogmodus gebunden sind, sondern weit 
über diese zeitliche und inhaltliche Arbeitsphase hinaus- 
reichen. 

Wird das Kommunikationsniveau D bei einer beliebigen EDV-Nu- 

tzung verstanden als Grad der aktivierten Dialogfähigkeit zwi- 

schen Benutzer mit seiner EDV-Aufgabe einerseits (Nutzersy- 
stem) und dem Computer und dem Betreiber von Computern als 

EDVsystem andererseits, so ergeben sich folgende Einflußgrös- 

sen auf D (Abb. 5 ): 

1.Funktionsteilung zwischen Benutzer und dem EDVsystem in be- 
zug auf Kommunikations- und Steuerungsaktivitäten. 

D, = Aktivitäten des Benutzers( Kommunikation und Steuerung) 
D, = Aktivitäten des Betreibers und Computers 

Dabei gilt: 

Dy ? Dr > die EDVsystem-Unterstützung tendiert zum Minimum 


83 


und damit zu einer. hohen Nutzerflexibilität. 
Dy=D; > Maximum an Dialogfähigkeit, das aber sehr kompliziert 
zu projektieren und zu beherrschen ist. 
DreBe > die EDVsystem-Unterstützung tendiert zum Maximum 
und damit. zu einem starren (fixierten) Leistungsange« 
bot mit geringen Nutzereingriffen (z.B. bei Infornma- 
tionssystemen). 
Die Relation Flexibilität Starrheit bestimmt in der EDV- 
Praxis viele soziale Auswirkungen der EDV-Nutzung, vor allen 
bezüglich des Niveaus von computergestützten Arbeitstätig- 
keiten,und damit das Niveau von gebliebenen oder verbliebe- 
"nen Arbeitsinhalten für den Menschen. 


= 
vv. i + zur 


kommüun.käfensinvenu ( D) 


in Meuell er Rbhangıs ker! des Armmonıkahenimnveng D 
Ein FR Jreaa 
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2. Das Zeitverhalten, d.h., die Reaktionszeiten des Partners( 
-systems) auf Fragen und Aufforderungen des Initiators, Sie 
bewegen sich für den PAFkH8Tzwischen einem Maximum und ei- 
nen Minimum. In diesem Toleranzraum, der individuell schwankt 
‚ muß sich ein Optimum befinden, das eine sogenannte " Er- 
träglichkeit der Reaktionszeit für den Partner sichert. 
Nach MARTIN / 6 / liegt die Toleranzbreite für den Compu- 
ternutzer zwischen 4 sec und 0,1 sec. 

3.Die Qualität der Austauschfähigkeit, d.h., die Adaption kom- 
nunkativer Aktivitäten ( Steuerungs- und Kommunikationsakti- 
vitäten) in bezug auf die "Verständnis-" Reaktion (Handlungs- 
reaktion) des Partners. Nan kann diese Größe durch. einen 
Koeffizienten d darstellen. 
Es gilt dannı 

oO<d<1, 

wobei bei Dy = Dr der Koeffizient einem Minimum entgegen- 
strebt. Der Koeffizient d „ den man bewerten kann mit Hilfe 
von Skalierungsverfahren für Kriterien von D , wird also be» 
einflußt von der Beziehung Dy D, , da mit wachsender 
Funktionsteilung die Qualität oder Güte der Dialogfähigkeit 
aus den o.g. Gründen (Anpassungsschwierigkeiten und -umfang) 
erschwert erreichbar und beherrschbar wird. 

4. Kommunikationsbarrieren (H) 

Kommunikationsbarrieren werden verstanden als Pifferenz 
zwischen projektierten und tatsächlichenKommunikationsni- 
veau D „ Ursächlich werden die Kommunikationsbarrieren von 
der Funktionsteilung, der Güte der Austauschfähigkeit und 
dem Zeitverhalten beeinflußt, d.h., je höher eine der drei 
Einflußgrössen effektiv an D partizipiert, umso größer wird 
der Einfluß von H auf diese Einflußgröße rekursiv sein. 
Biese Ableitung ist nur gegeben, wenn man die Kommurkations- 
barrieren als’eine Art "Fehler" auffaßt, deren Anzahl oder 
Aufkommen stochastisch mit der quantitativen Zunahflierseiner 
Einflußgrößen auf D anwachsen dürfte. ®o wird ‘bei ausge- 
glichener Relation Dy  D, infolge des notwendigen hohen 
Automatisierungsaufwandes und Änpassungsaufwandes von 
Kommunikationsbeziehungen auf informationeller Basis zwangs- 
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läufig der Anteil und Einfluß von Kommunikatiönsbarrieren zu- 
nehmen. 

Alle genannten Einflußgrössen sollten das Objekt von Gestaltungs 
-strategien des Betreibers und des Entwicklers von Computern 

in bezug auf EDV-Anwendungen bilden, 

Zwischen den 0.8. Einflußgrössen von D bestehen teilweise kom- 
plizierte Wechselwirkungen und Abhängigkeiten. 

Andererseits stellen der Anteil und das Niveau der’ aufgeführten 
drei Äktivitätengruppen in der EDV-Nutzung für den Analytiker 
eine wesentliche Aussage über den Charakter der konkreten EDV- 
Nutzung in bezug auf kreativitätsfördernde, ader persönlichkeits- 
entleerende Arbeitsinhalte von Tätigkeiten dar. Sie indizieren 
somit. wichtige soziale Auswirkungen der Computerisierung. 

Allen genannten Aktivitäten liegt eine Vielzahl von Entschei- 
dungen und damit von Entscheidungsprozessen zugrunde, denen 
sich der EDV-Benutzer stellen muß, oder die ihm das Rechner- 
system abnimmt. Diese Feststellung beinhaltet die eigentliche 
Ursacha für unmittelbare soziale, d.h., auf den EDV-Benutzer 
bezogene, Auswirkungen der Informationstechnologie im Arbeits- 
prozeß. 


In Anlehnung an die Struktur perzeptiv-intellektueller Leistun- 
gen nach PLATH / 17 / lassen sich für die einzelnen fätigkeits- 
arten in der EDV-Nutzung unterschiedliche Aussagen änführen, 
wobei wir nachfolgend 6 Tätigkeitsarten zugrunde legen. Abb. 6 
vermittelt eine entsprechende matrixartige Übersicht. Zu den 
Tätigkeitsarten gehören: 


- Dateneingaben s ZB. Patienteninformationen 
- Dateneingaben und vordefinierte 
Ausgaben „ ZB. rechnergestütztes 
Bestrahlungsplanungs- 
system 
- nur vordefinierte Ausgaben ‚ 2.B. Fahrplanmitteilungen 


per Display 


vordefinierte Ausgaben auf Anfragen, BeBel 2 Le LUEDERRERENE- 
system 


Instruktionen für DV-Prozesse ,„ ne Bo sabenk (Benu- 
tzung) 
Programmentwicklung (Programmierung). 
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Abb. 6 Struktur 3 EDV-Nutzungen (Arten) nach perzeptiv- 
kognitiven Merkmalen 


Erst bei letzterer, d.h., der Programnentwicklung, werden Kennt- 
nisse einer Programmiersprache benötigt. Andererseits setzt sich 
sich international der Anteil der übrigen ( 5 ) Tätigkeitsar- 
ten in der Informatiors technologie gegenüber der Programment- 
wicklung immer stärker durch, Diese Entwicklung provoziert gear. 
radezu Untersuchungen der Rolle und Funktion des EDV-Benutzers 
in der. EDV-Anwendung. 

Die EDV-Nutzung sollte also nicht zu eng nur unter dem Aspekt 
der Programmierung gesehen werden. Die eigentlichen sozialen 
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Auswirkungen entstehen vordergründig bei den anderen 0.g. Tä- 
tigkeitsarten der EDV-Nutzung. 

Die perzeptiv-kognitiven Leistungen umfassen (nach PLATH): 
- Orientierunssleistungen 

- Kontrolloperationen 

- Entschlüsselung von Informationen 

- Vorstellungsmäßiges Nachvollziehen bekannter Sachverhalte 
- Beurteilen 

- Entscheiden 

- zu aktualisierendes Wissen 

- Entwerfen 

- objektive Freiheitsgrade 


Die dargestellte Matrix läßt vermuten, daß sich das Niveau der 
geforderten perzeptiv-kognitiven Leistungen in Abhängigkeit 
von den jeweiligen EDV-Tätigkeitsarten verändert und in der 
Matrix allgemein von links nach rechts zunimmt, bei der 
Programmierung den Höhepunkt erreicht. 


5. Die arbeitsmäßige Umgebung des EDV-Benutzers 


Als arbeitsmäßige ‚Umgebung des EDV-Benutzers sollten gesehen 

werden: 

- die EDV-Aufgabe und ihre Lösungsanforderungen 

- der Umgang mit dem Rechnersystenm 

- die Integration in eine kooperative Gruppe 

- die Arbeitsumgebung mit ihren Anforderungs-, Ziel-und Wert- 

systemen 

Damit existiert auch eine soziale Kommunikation, die wesentlich 

die Motivation und Einstellung des Benutzers zur EDV stimuliert. 

Abb. 7 vermittelt diesbezüglich einen Überblick über die In- 

tensität ausgewählter Merkmale von Benutzergruppen am Beispiel 

der Forschung. Es wurden 6 Benutzergruppen untersucht: 

- die Systemprogrammierer, d.h., Mitarbeiter eines Rechen- 
zentrums 

- die Anwendungsprogramnierer 

- Fachwissenschaftler mit gesamter eigener Programmentwicklung 


- Fachwissenschaftler; definieren nur EDV-Aufgabe und nutzen 
Berechnungsergebnisse 
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- übrige Fachwissenschaftler; nutzen nicht die EDV 

Die untersuchten Merkmale zeigen ein unterschiedliches Bild 
der sozialen Kommunikation auf dem Gebiet der EDV: In Abhän- 
gigkeit vom persönlichen Arbeitsanteil an der EDV-Nutzung ver- 
ändert sich ihr Niveau, Es zeigt sich „ daß die zwischenmensch- 
liche Kommunikation durchaus als wichtige Ergänzung und nicht 
als Alternative zur Mensch-Rechner-Kommunikation zu bewerten 
ist, wenn der EDV-Benutzer als Mittelpunkt und Träger der EDV- 
Nutzung gesehen wird. 

Wird der Benutzer bedeutungs- oder rollenmäßig in den Nittel- 
punkt von EDV-Nutzungen bezüglich ihrer Projektierung und Ge- 
staltung gestellt und letzlich die EDV-Anwendung mit ihren 
Arbeitsergebnissen als"Finalprodukt" gesehen, so _ müssen zu- 


sätzlich auch kognitive und soziale Aspekte beim’ EDV-Einsatz 


berücksichtigt werden. 
Unter diesen Bedingungen läßt sich ein"Benutzerbild" als Zu- 


stand eines Menschen in der EDV-Nutzung beschreiben, der sich 
über ein EDV-Nutzungsverhalten individuell äußert, aktiviert 
und damit zu einer leistungsbeeinflussenden Komponente im 
Mensch-Maschine-Systen wird. Unter dieser. Voraussetzung kann 
der EDV-Benutzer nur in Verbindung mit seiner Umgebung, d.h., 
in seiner gesellschaftlichen Determiniertheit, bewertet wer- 
den. Damit abstrahieren wir bewußt von einer Aufzählung cha- 
rakterologischer Merkmale als Benutzerbild-Interpretäation, da 
diese individuell zu verschieden sind und nicht die wechsel- 
seitigen Beziehungen zur Umwelt ausreichend und verallgemei- 
nerungsfähig reflektieren. 


6. Verhalten, Kommunikation und Organisation als zentrale 
Begriffe in der EDV-Nutzung 

Mit diesen, Aussagen :wird dehonstriert, daß Verhalten, Kommu- 
nikation und Organisation inhaltlich sehr eng mit der Be- 
schreibung des EDV-Benutzers verbunden sind und künftig einen 
hohen Stellenwert in der Informatik erhalten sollten. Eine 
Beeinflussung des. Benutzers wird nur über die inhaltliche Be- 
rücksichtigung. dieser Begriffe bei der Ausbildung der EDV- 
Nutzung als oder im Arbeitsprozeß möglich. So wird schon jetzt 
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erkennbar, daß Inhalt und Bereitstellung hocheffizienter Kom- 
munikationsbeziehungen, oft nur für kurze Zeiträume, 2.B. wäh- 
rend einer Terminalsitzung, ein signifikantes Gestaltungsziel 
für EDV-Nutzungen bilden, die letzendlich auch die Einstellung 
des Benutzers zur EDV und damit auch die Ausnutzung der tat- 
sächlichen Möglichkeiten des Computers beeinflussen. 
Nachfolgend soll überblicksartig das Modell der Einflußnahme 
des EDV-Benutzers und seiner Position in der EDV vorgestellt 
werden, das insbesondere die Bedeutung und wachsende Brisanz 
der 0.8. 3 Begriffe betont (Abb. 8 ). Dabei werden die arbeitss 
mäßigen und psychologischen Einflußnahmen von 6 Komponenten 
aufgezeigt und zwar der Komponenten: 

-.fachliches Problem 

- abgeleitete EDV-Aufgabe 

- EDV-Nutzung als Arbeitstätigkeit 

- Computer 

- Effekt der EDV-Leistung bzw. des Finalprodukts 

- kooperierende Gruppe 

Es wird das Verhalten des Benutzers als Input- bzw Output- 
größe aufgefaßt, die sich innerhalb des Bezugrahmens oder 
Kontextes Kommunikation und Organisation modifiziert, wobei 
diesen Funktionen ein Wechsel von kollektiver und individuel- 
ler Tätigkeit als typisches Nerkmal vor allem der Programment- 
wicklung inhärent ist. Interessant bei dieser Modellvorstel- 
lung ist der Einfluß der kooperierenden Gruppe im Vorfeld der 
EDV-Nutzung auf den EDV-Benutzer, d.h., auf seine Persönlich- 
keit und das Verhalten als aktivierte Persönlichkeit. 
Zusammenfassend können wir feststellen und damit als Defini- 
tion fixieren: 

Unter einem EDV-Benutzer soll verstanden werden ein Individu- 
um mit einer EDV-Aufgabe, das zu ihrer Lösung gezielt EDV- 
Leistungen im Rahmen einer Mensch-Rechner-Kombination, insbe- 
sonders Leistungen des Rechners in Anspruch nimmt. Dazu sind 
beistungen des Benutzers ‚teilweise in Kooperation, zwecks Ver- 
arbeitung und Aufbereitung dieser Inanspruchnahme erforder- 
lich. Es entstehen bei der EDV-Nutzung als Arbeitstätigkeit 
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spezielle Verhaltensweisen und Kommunikationsbeziehungen, die 
in Wechselwirkung mitödem Rechner und/oder Rechnerbetreiber 
(Rechenzentrum) notwendig sind, und vom EDV-Benutzer mit einem 
vorwiegend perzeptiv-kognitiven Tätigkeitsaufkommen realisiert 
werden. Das Niveau der arbeitsmäßigen Funktions- und Aufgaben- 
teilung Benutzer - Rechner beeinflußt soziale Auswirkungen. 


Aus dem Obengesagten lassen sich für die Projektierung von 

EDV-Nutzungen einige interessante Schlußfölgerungen ableiten: 

1. Das Verhalten sollte als wesentliche Komponente für die Or- 
ganisation der EDV-Nutzung als Arbeitstätigkeit in bezug 
auf die soziale Integration, Gestaltung der Aufgabenteilung 
Mensch - Rechner, Ausbildung ihrer Kommunikationsbeziehun- 
gen sowie der Entwicklung des rechentechnischen Einsatzes 
unter dem Primat der Nutzungsfreundlichkeit berücksichtigt 
werden, 

2. Die Kommunikation ist als weitere wesentliche Komponente in 
bezug auf die Funktionsfähigkeit des Computereinsatzes, Re- 
alisierung arbeitswissenschaftlicher Aspekte bei der EDV- 
Nutzung sowie zur Produktivitäts- und Kreativitätserhöhung 
für den EDV-Banutzer einzubeziehen. 

3. Auffassung und Gestaltung des EDV-Einsatzes als gesell- 
schaftliches Anliegen, das nur interdisziplinär und unter 
Zugrundelegung von Leistungs-, Beanspruchungs- und persön- 
lichkeitsbildenden Faktoren als Einheit bei gleichzeitiger 
Berücksichtigung der sozialen und ökonomischen Effizienz 
und Auswirkungen optimal zu realisieren ist. 

4. Die Auffassung und Behandlung des EDV-Benutzers als "Durch- 
schnitts- oder typischen Nutzer" mit typischen Anforderun- 
gen und Verhaltensweisen ist nicht mehr ausreichend und 
führt über die übliche Einordnung in Nutzerkategorien nur 
zu bedingtem Aussagewert. Diese Aussage ist wichtig in Ver- 
bindung mit der Nachnutzungsproblematik in der EDV. 

5. ES besteht die Möglichkeit und Notwendigkeit einer Einfluß- 
nahme auf die EDV-Nutzung und damit auf den Benutzer durch 
Entwickler und Betreiber von Rechnern über die Ausbildung 
von geeigneten Kommunikationsbeziehungen,. Diese Einfluß- 
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nahme ist aber begrenzt aus fachlichen, zeitlichen und sozial- 
psychologischen, auch lokalen Gründen und sollte sich beziehen 


Be Be year ne een 
auf die unmittelbare Unterstützung und Stimulierung der EDV- 
Nutzung als Arbeitstüätigkeit. 


T» Schlußfolgerungen 


Zusammengefaßt ergeben sich verschiedene neue Fragestellungen 
für die Informatik in Verbindung mit der Erforschung des EDV- 
Benutzers wie: 


die Erforschung der Motivation zur EDV-Anwendung 
Eignungsgrenzen des Menschen in der EDV-Nutzung und ihre 
Berücksichtigung bzw. evtl. Erweiterung bei der bzw, mit 

der Hilfe der Gestaltung von rechnergestützten Informations- 
systemen und anderen Nutzungsarten der EDV 

Inhalt und Gestaltung persönlichkeitsbildender Faktoren bei 
der EDV-Nutzung 

Kommunikationsgestaltung als Örganisationsproblem 

in der EDV-Nutzung = 

individuelle Leistungs- und Persönlichkeitsunterschiede und 
ihre Berücksichtigung beim Einsatz dezentralisierter Infor- 
mationstechnologien 

die _ Berücksichtigung bzw. Adaption von computerseitigen In- 
novationen an das EDV-Benutzerverhalten und seine Merkmale 
Normierung und individuelle Freizügigkeit bei der Programn- 
entwicklung und überhaupt in der EDV-Nutzung - nicht als 
Widerspruch sondern als wechselseitige Ergänzung! 

die EDV-Nutzungsfreundlichkeit unter Berücksichtigung kog- 
nitiver und sozialer Aspekte 

das EDV-Nutzungsverhalten bei unterschiedlichen Informations- 
technologien 

die Rolle und Auswirkungen der EDV_im fachbezogenen Arbeits- 
prozeß des EDV-Benutzers (u.a. Notivations- und Einstellungs- 
hintergründe) 

Auswirkungen von EDV-Nutzungen auf die Persönlichkeit des 


‚Benutzers. 


Diese beispielartig aufgeführten Fragestellungen kreieren 


neben der Hardware und Software auch den Benutzer, den NMen- 


94 


schen, als Forschungsobjekt in der Informatik. 
Dabei söllten sich 4 Forschungsschwerpunkte herausbilden und 
zentrieren: 
das Nutzerverhalten 
- als psychologisch-soziales Phänomen unter 
den Bedingungen der EDV-Nutzung 
die EDV-Nutzung als Arbeitstätigkeit 
- vorrangig als arbeitswissenschaftliches 
Phänomen unter Berücksichtigung sozialer 
und ökonomischer Wirksamkeitsuntersuchun- 
gen des konkreten EDV-Einsatzes 
- die Kommunikationsgestaltung bei EDV-Nutzungen 
- vorrangig als Örganisationsphänomen nit 
dem Ziel der Schaffung von Entfaltungsbe- 
älngungen für Nutzersysteme 
gesellschaftliche und soziale Auswirkungen von Informations- 
technologien 


[3 


- im Sinne von Fern- und Nachwirkungen, 
wie z.B. Datenschutz, juristische Fragen 


Vorliegende Ausführungen sollen Anregungen in diesem Sinne 
vermitteln. 
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Anforderungen an Spezifikationsmittel im Programmentwicklungs- 
prozeß BR: 


1. Einleitung 
Im Verlauf der stürmischen Entwicklung auf dem Gebiet der 


Software- Technologie haben sich Inhalt und Breite des Begriffes 
Spezifikation verändert. Neben der stärkeren Betonung früher 
Entwurfsstadien werden Spezifikationsmittel auch in der Phase 
der Installation/Wartung eingesetzt, sodaß ihre Nutzung prak- 
tisch alle Phasen des Lebenszyklus von Software umfaßt. 

Die Erweiterung des Aufgabenspektrums ist in engem Zusammen- 
hang mit den erweiterten Auffassungen des Software- Lebens- 
zyklus zu sehen, da sich die Aufstellung der Spezifikationen 
und ihre Anwendung im Gesamtprozess der Software- Produktion 
einordnen, siehe /FIKO/, /COCO/, /HÜNK/, /RIFA/, /HOFF/: 
Trotz dieser Ausweitung des Einsatzepektrums bleiben Spezi- 
fikationen im wesentlichen Aufgabenbeschreibungen, die auf 
deskriptive Weise ausdrücken, was gefordert ist, im Gegensatz 
zum wie der programmiersprachlichen Formulierung. 


2. Einflussgrößen für Anfoderungen 
Ein wesentlicher Gesichtspunkt im Rahmen der Software- Techno- 


logie ist die Erstellung von Software mit Produktcharakter. 
Zur näheren Erläuterung des Begriffs können verschiedene 
Punkte angeführt werden, 

Entwickler und Nutzer sind nicht identisch. 

Es arbeitet eine größere Gruppe von Entwicklern. 

Die Software ist Bestandteil anderer Produkte, 

Es sind mehrere Varianten der Software vorgesehen. 

‚Für sogeartete Software- Produkte erlangt die Frage der 
zugehörigen Spezifikation tiber den gesamte Prozess ihrer 
Erstellung verstärkte Bedeutung, da sie Qualität, Nutzbarkeit, 
"Lebensdauer usw, beeinflussen, 

Art, Umfang und’Anforderungen an die Spezifikationen hängen 
dabei vom Umfeld der zu lösenden Probleme sowie deren Rand- 
bedingungen ab. Neben der ökonomischen zielstellung, die 
Forderungen hinsichtlich Nachnutzbarkeit, Portabilität und 
Lebensdauer der Software impliziert, ist das Einsatzgebiet von 
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großer Bedeutung. So ist für die Spezifikation sicherheits- 
relevanter Systeme wie Verkehrssteuerungen ein höherer Aufwand 
bzgl. Genauigkeit und Überprüfbarkeit notwendig als für komnerz- 
ielle probleme Probleme der ökonomischen Datenverarbeitung, 
2.B./GOTT/,/VOGE/. Außerdem spielen die Qualifikation und Vor- 
stellungswelt des Nutzers eine Rolle, um für diesen die Spezi- 
fikation während der Software- Entwicklung und Nutzung sowie 
bei der Beschreibung des Ausgangsproblems verständlich zu 
machen.Last not least entstehen im Produktionsprozess der Soft- 
ware Anforderungen an die Spezifikation, deren Wichtung für die 
einzelnen Entwicklungsphasen unterschiedlich ist. Die Anforde- 
rungen, die durch die oben genannten Faktoren beeinflußt werden, 
sollen im folgenden anhand der Entwicklungsphasen der Software 
untersucht werden. In diesem Zusammenhang setzen sich inter- 
national verstärkt Auffassungen einer dualen Sicht der Software- 
Produktion durch, die neben der Dekomposition in kleinere Teile 
beim Systementwurf dual dazu der Zusammenbau der Einheiten bei 
der Systemintegration betrachten. Im Zusammenhang mit Spezi- 
fikationsaktivitäten ergibt sich ähnliches, da eine Dualität 
zwischen der Beschreibung der Funktion der Bausteine (Spezi- 
fikation) und der Überprüfung der Funktion der Bausteine 
(Validation) besteht. 
Demzufolge werden nicht. nur Anforderungen zum Beschreibungs- 
aspekt, sondern auch zum Überprüfungsaspekt betrachtet. 
- Spezifikationen müssen möglichst abstrakt sein,. d.h. noch von 
der programmtechnischen Realisierung entfernt sein. 
- Sie müssen schon so formal sein, daß sie automatisiert verar- 
beitet werden können. 
- Sie miissen es erlauben, Unvollständigkeiten auszudrücken. 
- Sie mlissen flexibel handhabbar, d.h. leicht änderbar sein. 
- Sie müssen für alle am.Entwurf Beteiligten verständlich sein. 
- Sie müssen es erlauben, das gewünschte Systemverhalten korrekt 
auszudrücken. 
- Sie miissen die Überprüfung ihrer Gültigkeit erlauben, d.h. 
- der Vollständigkeit, 
- der Widerspruchsfreiheit und 
- der Konsistenz. 
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Diese Anforderungen sind für unterschiedliche Anwendungen und 
Entwicklungsphasen der Software von unterschiedlicher Wichtung. 
Das schlägt sich auch in verschiedenen Systematisierungsver- 
suchen in der Literatur nieder, worin Spezifikationsmittel 

und -methoden nach bestimmten Anfoderungen bzw. Einsatzgebieten 
geordnet werden. So wird bei /HESS/ in der von ihm 'Software- 
entwicklungslandschaft' genannten Darstellung nach Formalität, 
Abstraktheit und Automatisierbarkeit geordnet. 

Im folgenden soll eine Systematisierung der Anforderungen 
anhand ihrer Wichtung im Verlauf des Entwicklungsprozesses 
versucht werden. Die Maßstäbe sind symbolischer Natur, da sich 
nicht auf ein konkretes Phasenmodell der Software- Entwicklung 
beschränkt werden soll; der Variantenreichtum für diese Modelle 


18t außerordentlich groß. 
17. = 7700 frühe Entwurfsphase 


Gültigkeit 


Korrektheit bzgl. 
Systemverhalten 


Bedeutung 


Formalität 


\ 


Abstraktheit un 


‚allg.Verständlichkeit 


ER l “ Br 
R | . . . 
f 
Ausdrücken von : 1 
Unvollst ändigkeiten —| 


Problem h Realisierung 
Entwicklungsprozess 


Abb. 1: Wichtung der Anforderungen an Spezifikationsmittel 
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Um ‚Schwerpunkte für die Software- Produktion zu setzen, müssen 
die Einflüsse der Entwurfsphasen auf die Qualität der Software 
untersucht werden. . Betrachtet man z.B. die Fehlerquote bzgl. 
der Gesamtfehler für die frühe Entwurfsphase, so beträgt diese 
ca. 50%, wobei aber dafür 80% der gesamten Fehlerbeseitigungs- 
kosten anfallen /BEICH/. Diese hohen Kosten entstehen dadurch, 
daß spät gefundene Entmurfsfehler aufwendige Korrekturen 
erfordern. Bei der Betrachtung des Gesamtzeitaufwandes werden 
in der Literatur durchschnittlich 50% der frühen Entwurfsphase 
zugeordnet. In dieser Phase sind viele grundsätzliche Probleme 
zu lösen und wichtige Entscheidungen für die nächsten Entwurfs- 
schritte bis hin zur Realisierung zu treffen. Daher: erscheint 
eine Konzentration auf Probleme der frühen Entwurfsetappen 
dringend geboten. 


3. Probleme der frihen Entwurfsphase 
Bei der Betrachtung dieser Phase erweist sich die Darstellung 


der Anforderungs- Wichtung als nützlich. 

Es gilt für die zu lösenden Software- Probleme eine Darstellung 
von hoher Verständlichkeit zu finden, die aber trotzdem auf 
Grund ihrer wachsenden Formalität schon Überprüfungen zum 
gewünschten Systemverhalten und zur Gültigkeit zulässt. 

Die Formullerung der Probleme besitzt noch einen hohen Grad an 
Abstraktheit, d.h. sie ist noch sehr maschinenfern, und erlaubt 
solche Unvollständigkeiten auszudrücken, die durch die noch 
nicht abgeschlossene Problemanalyse verursacht werden. 

In dieser Phase wird angestrebt, das.Ergebnis der Problemana- 
lyse möglichst informal auszudrlicken, aber schon Möglichkeiten 
für die rechnergestützte Verarbeitung und Überprüfung zu schaf- 
fen. Es wird somit ein Modell der Problemlösung aufgestellt, 
das eine anschauliche, fachlibergreifende (bzgl. des Bearbeiter- 
kreises) Darstellung erlaubt und für alle am Entwurf Beteilig- 
ten die Entwicklungsschritte verständlich und kritisierbar 
machen soll. 

In Anlehnung an die Anforderungen an Spezifikationsmittel 
können abgeleitete Forderungen an ein Modell in einer frühen 
Entwurfsetappe formıliert werden, 
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Ein Modell 
- mıß die wesentlichen Eigenschaften des Objekts beschreiben. 
(Gültigkeit bzgl. Systemverhalten) 
- muß "in irgend einem Sinne leichter zugänglich sein'. 
(Verständlichkeit,) 
- muß flexibel und änderbar sein. 
(informal, Ausdruck von Unvollständigkeiten) 
- darf nur Funktionen des zu realisierenden Systems beschreiben, 
die durch dessen innere Logik bestimmt sind. 
(Abstraktheit) 
- muß analysierbar sein, sowohl manuell als auch automatisiert. 
(Formalität, Verständlichkeit, Gültigkeit) 
In einem solchen Modell werden alle Anforderungen an das zu 
realisierende System zusammengefaßt, zur Bezeichnung dieser 
Anfarderungen hat sich in der Literatur der englische Begriff 
requrement eingeblirgert. Dieser soll auch hier verwendet werden, 
um Verwechselungen zu dem im Titel genannten Begriff zu ver- 
‚meiden, 
Zur Aufstellung und Bearbeitung .der requirements sind viel- 
fältige Aktivitäten notwendig, siehe /KSCH-./,/HAMÜ /,\ die im 
nachfolgenden Bild zusammengefaßt werden sollen. 


Ermittlung Beschreibung Analyse 
requirements 
Auftraggeber 
Welterentwicklg. Kommunikation | Entwickler 
Nutzer 
Präzisierung & Überprüfung 
- Vollständigkeit 
Gültigkeit I wWiderspruchsfreiheit 
Konsistenz 


Abb. 2; requirement- Aktivitäten 
Neben zahlreichen anderen Problemen sollen hier abschließend 


zwei Hauptprobleme der requirement- Aktivitäten angedeutet 
werden. 
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1. Die Aktivitäten zur requirement- Spezifikation stellen 
keinen deterministischen Prozess dar, Auf Grund der ent- 
haltenen Unvollständigkeiten, der hohen Flexibilität sowie 
der Vielschichtigkeit des Entwurfsprozesses sind der Auto- 
matisierung Grenzen gesetzt. Daher wird auf diesem Gebiet 
eine interaktive Arbeitsweise unabdingbar. 

2. Besonders in frühen Stadien der Software- Produktion sind 
fachlich unterschiedlich gelagerte Interessen- und Arbeits- 
gruppen am Entwurf beteiligt. Grob gesagt handelt es sich 
datei um - Auftraggeber 

- Entwickler 

- Nutzer. 
Bei der. dabei nötigen Kommunikation zwischen den Gruppen 
ist eine interdisziplinäre Arbeitsweise unbedingt notwendig. 
Grob verallgemeinert kann man den Ablauf folgendermaßen 
darstellen. 


Auftraggeber/Nutzer Pr 
| _ Modell 5 
4 Entwickler- 
Vertragsgnftlage, Pflichtenheft? 


Abb. 3: Interdisziplinäres Entmurfsschema 


‚Gerade für die Realisierung von Software mit Produkt- 
charakter ist dieser üÜberlappenden Etappe große Aufmerk- 
samkeit. zu schenken, um eina wohldefinierte Arbeitsgrund- 
lage zu erhalten, 
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Leistungsboewertung im Rechenbetrieb 


Doz. Dr. sc. techn. Gerhard Bergholz 
Technische Universität Dresden 


1, Einführung 
Mit der gewachsenen Verbreitung der Rechentechnik wurde die 
effektive Nutzung der Ressourcen einer Rechenanlage zu einen 
Erfordernis. Der gegenwärtige internationale und nationale 
Stand ist dadurch gekennzeichnet, daß eine Diskrepanz zwischen 
den bereitgestellten Ressourchn und ihrer Nutzung vorhanden 
ist. In der Tabelle 1 werden die prozentualen Auslastungen 
der Ressourcen: Hauptspeicher (HS), NMagnetplattengeräte (IIP6), 
Magnetbandgeräte (MBG) und Paralleldrucker (PD) für eine Rechen- 
anlage EC 1040 angegeben, die aus Nessungen gewonnen wurden, 
Keine der betrachteten Ressourcen ist über 50% ausgelastet. 
Zur Beseitigung der oben genannten Diskrepanz wurden im 
letzten Jahrzehnt international Mittel und 'Methoden entwickelt, 
die in der Forschungsdisziplin Leistungsbewertung von Rechner- 
systemen zusammengefaßt werden. Hauptanwendungsgebiet der 
Leistungsbewertung von Rechnersystemen ist der praktische Rechen- 
betrieb. Damit bildet die Leistungsbewertung im Rechenbetrieb 
eine wichtige wissenschaftliche Grundlage für die Technologie 
des Rechenbetriebs. 
Hauptgebiete der internationalen Forschung auf dem Gebiet der 
Leistungsbewertung sind: die Schaffung von Verhaltensnodellen 
(empirische, analytische und Simulationsmodelle) als Grundlage 
für die Leistungsvorhersage, die Schaffung von litteln der 
Leistungsmessung und schließlich die Nutzung der Verhaltens- 
modelle und Nittel der Leistungsmessung für die Leistungsver- 
besserung und den Leistungsvergleich, 
Die Ergebnisse der internationalen Forschung werden in Litera- 
turübersichten /1/ und /2/ und einer Anzahl von Büchern, ins- 
besondere in /3/ zusanınenfassend dargestellt. Uber- das Gebiet 
der Leistungsbewertung von 'Rechnersystemen fand eine größere 
Zahl von Spezialtagungen statt, deren Vorträge in Sammelbänden 


- 
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veröffentlicht werden (siehe ZeB. /4/). Seit 1981 erscheint 
die internationale Zeitschrift "Performance Evalu,sation"”, 

In diesem Beitrag werden die Begriffe der Leistungsbe- 
wertung unter Nutzung konkreter eigener Untersuchungen des 
Autors dargelegt. 


2. Leistungsbewertung von Rechnersystenen 


Die Leistungsbewertung von. Rechnersystemen beschränkt sich 
auf die Bewertung von Eigenschaften der Hechnerinstallation, 
die quantitav bewertbar sind. Der Vorteil dieser Beschränkung 
besteht derin, daß auf dieser Grundlage eine Theorie aufge- 
baut werden kann, in der quantitative Größen als wesentliche 
Parameter eingeschlossen sind. 

In der Literatur (siehe z.B. /2/) wird eine größere Zahl von 
Größen für die Bewertung der Rechnerleistung genutzt. iian 
kann diese Bewertungsgrößen in drei Hauptklassen einteilen: 
in Bewertungsgrößen, die des Durchsatzverhalten ausdrücken, 
in Bewertungsgrößen, die das Reaktionsverhalten ausdrücken 
und in Bewertungsgrößen, die das Auslastungsverhalten aus- 
drücken. Konkrete Bewertungsgrößen werden in diesem Beitrag 


später in Zusammenhang mit konkreten Untersuchungen einge- 


führt. Der Gegenstand der Leistungsbewertung besteht in der 
Schaffung von Iitteln und Methoden der Leistungsbewertung 

und in der Nutzung dieser Mittel und Wethoden, Leistungsbe- 
wertungsmittel sind vor allem Verhaltensmodelle und ließmittel. 
Nutzungsrichtungen der Leistungsbewertung sind die Leistungs- 
verbesserung, der Leistungsvergleich und die Leistungsvorher- 
sage, z.B. für die Planung. 


2,1. Verhaltensmodelle 


Ein Verhaltensmodell beschreibt den Zusammenhang zwischen unab- 
hängigen Zinflußgrößen und Bewertungsgrößen B, Die unab- 
hängigen kEinflußgrößen können in Arbeitslastparaneter ä und 
Konfigurationspareweter S unterteilt werden. Formelmäßig 

kenn dann allgemein geschrieben werden 


B=B(A, S) (1) 
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und als Blockschema für. das Rechnersystem ergibt sich die 
Abbildung 1. Wir können die Verhaltensmodelle in die drei 
Nodellklassen: empirische liodelle, Simulationsmodelle und 
analytische lodelle unterteilen, In den Verhaltensmodellen 
werden liethoden der Wahrscheinlichkeitstheorie und mathema- 
tischen Statistik angewendet. 

Bine wichtige Eigenschaft eines Verhaltensmodells ist seine 
Adäquatheit, die man praktisch als Übereinstimmung der mit 
dem Verhaltensmodell gewonnenen theoretischen Ergebnisse mit 
den realen Bedingungen am Rechnersysten auffassen kann. Wenn 
die Anwendung von Verhaltensmodellen zu richtigen Ergebnissen 
führen soll, ‘dann muß mit. adäquaten Verhaltensmodellen unter- 
sucht werden. Deshalb bildet. die’Untersuchung der Adäquatheit 
von Verhaltensuodellen, die auch Validierung genannt wird, 
eine wichtige Etappe bei der Aufstellung von Verhaltensmodellen, 
Eine Wöglichkeit der Untersuchung der Adäquatheit eines Ver- 
haltensmodells besteht in folgenden Vorgehen. Dazu betrachten 
wir das Rechnersysten mit den Arbeitslastparanetern A, den 
Konfigurationsparanetern S und den Bewertungsgrößen B und das 
Verhaltensmodell des Rechnersystems mit. den Arbeitslastpara- 
metern A', den Konfigurationsparametern S' und den Bewertungs- 
größen B' (siehe Abb. 3) unter den Voraussetzungen 


A=ı' L 
S=Ss!, ( (2) 


= 


Dabei werden die Bewertungsgrößen B und B' verglichen. Zum 
Beispiel kann als liaß für die Adüquatheit IB-B'| genutzt 
werden und auf dieser Grundlage der Grad der Übereinstimmung 
des Vernaltensmodells mit dem realen Rechnersysten bestimmt 
werden. Die Größen A, 5 und B des Rechnersystens nüssen dabei 
durch Messungen gewonnen vrerden. 

‚ir betrachten jetzt als Beispiel eines Verhaltensmodells die 
Abhingigkeit der Rechnerleistung L von der Verteilung der 
Systendateien über die Plattenstapel und Zylinder der Platten- 
stapel. Dieser Zusammenhdng kann über zwei „odellstufen, ..odell 
der Systeuplatten und Leistungsmodell (siehe \bb. 3), herge- 
stellt werden, wobei 
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L= L(T _,M) (3). 
und 


T = T 514,8) (4) 
gilt. Hierbei werden die Bezachnungen 


L - Rechnerleistung (Durchsatzrate in Arbeitseinheiten/Zeit- 
einheit, z. B. Anzahl der phys. Sätze/s) 


Ds - ınittlere Positionierzeit aller Systemplatten 
k - lultiprogramnfaktor 


D1,;, ..., Dn - Systemdateien 


& =(8. ..., &,) - Vektor der Plattenstapelnumnern der 
Systendateien D, (i=1,00.,20) 


da =(d,seee,d,) - Vektor der Zylinderanfangsadressen der 
Systemdateien D, (i=a1,.04,n) 


genutzes 


2.2. Leistungsmessung 


Unter der Bezeichnung Leistungsmessung wird die meßtechnische 
Erfassung (einschließlich statistische Verdichtung) der Arbeits- 
lastparameter A und der Bewertungsgrößen B verstanden, Die 
Leistungsmessung bildet gemeinsam mit den Verhaltensmodellen 

die Grundlage für die Leistungsverbesserung im Rechenbe- 

trieb. und für den Leistungsvergleich verschiedener Rechnerkon- 
figurationen; Sie wird außerden für die Adäquatheitsüber- 
prüfung der Verhaltensmodelle genutzt, ; 

Gewöhnlich erfolgt die Leistungsmessung in zwei Stufen in 

der Stufe der ließwerterfaessung und. der Stufe der keßwertaus- 
wertung. Debei wird bei ereignisorientierter liessung während 

der hießwerterfassung eine Ereignisfolge (Trace) erfaßt und 
aufgezeichnet und während der ließwertauswertung die den ein- 
zelnen Ereignissen zugeordneten Daten zu Littelverten, Vertei- 
lungsfunktionen usw. verdichtet, 

Wir wollen hier keine. Unterscheidung zwischen speziellen ließmoni- 
toren und allgemeinen Weßmitteln, die vor allem der Abrech- 

nung dienen, machen, 
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Für ESER-Anlagen stehen für das Betriebssystem’ SMF SMF /8/ mit 
spezifischen Auswertungsprogrammen, das GTF /9/ mit dem 
GTFUON /iY als Auswertungsprogramm und LIX /1/ zur Verfügung. 


2.3. Leistungsmonitor EAWON 


Die oben angeführten Neßmittel dnügen nicht allen Anforde- 

rungen, die für bestimmte Leistungsbewertungen erforderlich 

sind. Deshalb wurde in Zusammenarbeit zwischen der Tech- 

nischen Universität Dresden und dem Datenverarbeitungszent- 

rum Dresden ein Leistungsmonitor EANMON als Laborprogramm 

für 0S/ES implementiert, erprobt und an einer ESER I-Anlage 

genutzt. 

Das Hauptziel von EANON bestand darin die E/A-Bedienungs- 

zeiten der einzelnen E/A-Geräte: Nagnetplattengeräte (MPS7,. 

Magnetbandgeräte (IBS), Paralleldrucker (PD) usw. meßtechnisch 

unter Umgehung einer genauen:Uhr zu erfassen, Für ein Hagnet- 

plattengerät setzt sich die E/A-Bedienungszeit aus drei An- 

teilen zusammen: aus der Positionierzeit T_ ‚,’aug der! Suchzeit 

T, und aus der Transferzeit T,; (siehe Abb. 4). Bei den anderen. 

Geräten fallen Positionierzeit und| Suchzeit wog. 

Die Grundgedanken von EAMON bestehen 

- in einer getrennten Bestimmung der Positionierzeit Ip» der 
Suchzeit T, und der Transferzeit Tr 

- in einer indirekten Bestimmung der Zeiten T_, Ts und. T; über 
die Erfassung der Geräteadressen s Zylinderadressen, Daten- 
trägernamen und Blocklängen der physischen Sätze und 

- in der Nutzung der Eichkurve für den Zusammenhang zwischen 
Zylinderabstend K und Positionierzeit E08 


Erfassung und Aufzeichnung einer Ereignisfolge (Trace) in EANON 


Nach jeder E/A-Unterbrechung erfolgt der Einsprung 'in das 
Erfassungs- und Äufzeichnungsprogramm von EANON. Dieses Pro- 
gramm erfaßt die Ereignisinformation, die dem Ereignis E/A- 
Unterbrechung zugeordnet ist und zeichnet diese in einen 
Monitorsatz auf liagnetband auf. Jedem Ereignis ist somit 

eine Ereignisinformation zugeordnet, Diese besteht aus der 
‚Geräteadresse, der Zylinderadresse, der Blocklänge, dem Daten- 
trägernanmen und der Uhrzeit. Die Uhrzeit dient nicht zur 
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Berechnung der E/A-Zeiten, sondern kann ifür die Zätsynofonisation 
mit anderen Meßmitteln (z.B, SMF) gemutzt werden. Es wird so- 
mit eine Folge von Ereignisinformationen in der zeitlichen 
Reihenfolge des Auftretens der Ereignisse aufgezeichnet. 

Diese Folge heißt Ereignisfolge (Trace). 


Bestimmung der Eichkurven für die Positionierzeiten 


während die Bestimmung der Suchzeit und der Transferzeit un- 
problematisch ıst , müssen für die Bestimmung der Positionler- 
zeit Eichkurven aufgenommen werden. Hierzu wurden 2 Eich- 
programme für ESER I und ESER II und ein Interpolationspro- 
gramm implementiert. Mit diesen Eichprogranmen wurden 25 lNag- 
netplattengeräte: 

5 ‘(-MByte-Plattengeräte 

16 29-MByte-Plattengeräte ” 

3 100-MByte-Plattengeräte 

1 200-MByte-Plattengerät 
ausgemessen, wobei insgesamt mehr als 100 Eichkurven für alle 
möglichen Zylinderabstände tabellarisch aufgenommen wurden. 
In der Abb. 5 ist für ein liagnetplattengerät vom Typ EC 5061 
(29 MWByte) die gemessene Abhängigkeit der Positionierzeit T 
vom Zylinderabstand k graphisch aufgetragen. Die Eichkurve 
des Zusammenhanges 


T, m T,0k) (5) 


wird im Auswertragsprogramm des EAHON genutzt. 


Statistische Verdichtung in EANON 

Wir beschränken uns hier auf die Verdichtung der Zylinder- 

adressen aus der Ereignisfolge. Hierbei gibt es zwei Aufgaben 

der Verdichtung 

- die Schätzung der Zugriffswahrscheinlichkeiten p;, zu den 
Zylindern i (i=1,...,N) mit N als Zylinderzahl eines Platten- 
stapels und 

- die Schätzung der Zylinderabstandswahrscheinlichkeiten pP, 
für die Zylinderabstände k = li-jl[, wenn i Augenblickliche 
Zylinderadresse und j die vorangehende Zylinderadresse in 
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der Ereignisfolge sind. 
Durch’ die Schätzung der Zugriffswahrscheinlichkeiten Pi zu den 
Zylindern i können bei Kenntnis der Dateiverteilung über die 
Zylinder die Zugriffshäufigkeiten zu den Dateien bestimmt 
werden. Das wird später noch genutzt, 
Die Schätzung der Zylinderabstandswahrscheinlichkeiten pP. kann 
für die Bestimmung der mittleren Positionierzeit In genutzt 
werden, wobei gilt 


In dieser Formel werden die P, aus den Zylinderadressen der 
Ereignisfolge in EAUMON und die T_(k) aus einer abgespeicherten 
Eichtabelle der entsprechenden Geräteklasse, die vorher über 
ein Eichprogramm bereitgestellt wurde, gewonnen. In 

der Abb, 6 ist die aus dieser Messung gewonnene‘ Zylinderab- 
standswehrscheinlichkeitsverteilung eines Hagnetplattenstapels 
angegeban. 


3. Nutzung der Leistungsbewertung für die Leistungsverbesserung 


Gegenwärtig ist die Leistungsverbesserung im Rechenbetrieb 

die Hauptrichtung der Anwendung der Leistungsbewertung. 

Die wichtigsten Wöglichkeiten der Leistungserhöhung auf 

der Grundlage der Leistungsbewertung bestehen in 

- einer geeigneten Wahl der gerätetechnischen Rechnerkonfi- 
guration 

- einer geigneten Planung der Betriebssystemgenerierung 

- einer geeigneten Wahl der Start- und Auswahlprioritäten für 
die Job- und Taskabfertigung und 

- einer geeigneten lischung der Arbeitslast. bei der Haschinen- 
'belegung. 


3s1. Öptimale Verteilung der Systemdateien 


Nachfolgend wollen wir uns auf ein Beispiel der Leistungs- 
erhöhung beschränken, das aus der optimalen Verteilung der 


Systemdateien über die Plattenstapel und Zylinder der Platten- 
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stapel besteht. Dieses Beispiel gehört zur geeigneten Planung 
der Betriebssystemgenerierung. 
Die Ziele der optimalen Verteilung der Systemdateien über 
die Systemplatten bestehen im Lästausgleich zwischen den 
geteilt genutzten Ressourcen (siehe /5/) und im Erreichen 
einer möglichst geringen mittleren Positionierzeit der Systen- 
dateizugriffe, 
Im konkreten Fall kann diese Aufgabe als Umverteilung der 
Systemdateien gegenüber einer bereits vorhandenen Verteilung 
der Systemdateien über die Systenplatten aufgefaßt werden, 
In diesem Fall bilden die gegenwärtige Verteilung der System- 
dateien und die Zugriffshäufigkeiten zu den einzelnen Systen- 
dateien den Ausgangspunkt der Untersuchung. Diese Informationen 
können durch maschinelle Erfassung der Dateiverteilung aus dem 
VTOC und durch Verdichtung der E/A-Ereignisautzeichnung des 
EAMON in den Zugriffshäurigkeiten p, zu den Zylindern und 
‚damit zu den Dateien gewannen werden. In Abb. 7 ist die Ver- 
teilung der mittleren Zylinderpositionierhäufigkeiten über die 
Zylinder der beiden Systemplatten DP 9851 und DP 9852 aufge- 
tragen. In dieser Abbildung wurde aus Darstellungsgründen für 
die einzelnen Dateien eine Gleichverteilung angenommen. Die 
Nessung, aus der diese Darstellung gewonnen wurde, enthält 
die reale Verteilung über die Zylinder auch innerhalb der 
Dateien. 
Auf der Grundlage dieses Meßergebnisses kann eine optimale 
Verteilung der Systemdateien vorgenomnen werden. Außerdem 
ist noch das in Abschnitt 2.1 angegebene Beispiel eines Ver- 
haltensmodells für die Abhängigkeit der Rechnerleistung von 
der Verteilung der Systemdateien über die Plattenstapel und 
Zylinder der Plattenstapel (siehe Abb. 3) zu nutzen. Auf der 
Grundlage dieses lLiodeLls ergibt sich der aus folgenden zwei 
Lösungsetappen bestehende Lösungsweg: 
- aus der optimalen Verteilung der Systemdateien zwischen den 
verschiedenen Systemplatten, die zum annähernden Lastaus- 
gleich zwischen den Systemplatten führt (siehe /5/, /b/)ur.t 
- aus der optimalen Verteilung der Systemdateien jeder Systenm- 
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platte über die Zylinder, die als Ergebnis einer Positionier- 
Zeitverkürzung gegenüber der vorhandenen Systemdateiver- 
teilung hat (siehe /7/). 

Nachfolgend werden beide Etappen kurz behandelt und die 

dabei zu erwartenden Leistungsverbesserungen geschätzt, 


3.1 Optimale Verteilung der Systemdateien zwischen den Systen- 
platten 
Als Grundlage für die optimale Verteilung der Systemdateien müssen 
die Zugriffshäufigkeiten Pi zu den Systemdateien gemessen 
werden. Unter Nutzung dieser Mepgrößen P; kann dann die 
Zuordnung der Systemdateien zu den Plattenstapeln erfolgen. 
Dabei erfolgt die Zuordnung nach ‘der Regel "die Datei mit der 
größten Zugriffshäufigkeit zuerst" (GZ2-Regel). Bei der GZ-Regel 
werden die Systemdateien ihrer Zugriffshäufigkeit entsprechend 
in einer Tabelle geordnet, wobei die Datei mit der größten Zu- 
griffshäufigkeit an der Spitze steht (siehe Tabelle '2). Aus 
dieser Tabelle werden die ersten r Dateien auf die r System- 
platten aufgeteilt. Die Platte mit den wenigsten Zugriffen, 
erhält dann die nächste Systemdatei zugeteilt. Anschließend 
erhält wiederum die Platte mit den wenigsten Zugriffen die 
nächste Datei zugeordnet usw. Dieser Zuteilungsprozeß ist 
abgeschlossen, wenn alle in der Liste stehenden Systemdateien 
einem Plattenstapel zugeordnet ‚sind. Falls einer der Platten- 
stapel während des Zuteilungsprozesses zylindermäßig voll 
ausgelastet ist, dann werden von diesem Zeitpunkt an nur noch 
den anderen Systenplatten Dateien zugeordnet, In der Tabelle 3 
sind die Ergebnisse der Umverteilung bezüglich der Zugriffs- 
häufigkeiten zu den zwei Systemplattenstapeln DP 9851 und 
DP9S52 angegeben. Außerdem werden zum Vergleich die gegen- 
wärtigen Zugriffshäufigkeiten Zu diesen Systenplatten mit in die 
Tabelle eingetragen. Es zeigt sich, daß einerseits die gegen- 
wärtigen Zugriffshäufigkeiten mit 36% zu 64% erheblich von 
einer ausgeglichenen Lastverteilung zwischen den Systenplatten 
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abweichen und daß andererseits durch die GZ-Regel im vor- 
liegenden roalen Fall mit den optimalen Zugriffshäufigkei- 
ten 51% zu 49% eine gute Annäherung en eine ausgeglichene 
Lastverteilung zwischen den Systemplatten erreicht wird. 


3.2. Optimale Verteilung der Systemdateien tiber die Zylinder 
der Plattenstapel 


Hler besteht das Ziel der optimalen Verteilung in der kMini- 
mlerung der mittleren Positionlerzeit 2, beider Systemplatten, 
wobei für eine Systemplatte eilt 
$ & 
2-2.8 pllisil)e (7) 
Dei ws “ jro ı )J pP | 

In diesem Ansatz würde statistische Unabhängigkeit der Zu- 
griffe zu den Systemdateien angenommen, Die optimale Form 
der Verteilung der Zugriffhäufigkeiten Über die Zylinder 
ähnelt einer Glockenkurve- (siehe Abb, 8). 
Ein Lösungsweg dieser Aufgabe, der ein quasioptimales Ergebnis 
liefert, besteht aus folgenden zwei Schritten, Als erstes wird 
jeder Datei des betrachteten Plattenstapels eine Ordnungszahl k 
nach der Größe der Zugriftshliufigkeit pro Zylinder p;. (der 
Datei 2,) zugewiesen, Ansohließend werden die Dateien von 
innen näch außen nach einer der Anordnungen 


N-1,0005,3,1,2,4,0..N 
oder 
N, 004,4, 2,1,3,5, 050, 0-1 


über die Zylinder des Plattenstapels verteilt, Hierbei ist N 
die Zahl der Systeudateien des betrachteten Plattenstapels. 
Der 5oestimntheit halber wurde N gerade angenommen, 

Dieser Lösurigsweg wurde auf die beiden Plattenstapel DVP 9451 
und DP 9552 angewandt, nachdem vorher didoptimale Verteilung 
der Dateien zwischen den beiden Plattenstapeln vorgenommen 
vurdes Im örgebnis dieser Neuverteilung der Dateien wurden die 
in abbs 3 engegebene Verteilung der mittleren Zylinderpositionier- 
näuriskeiten liber die Zylinder der beiden Plattenstapel er- 
halten. Die ultileren Positionierzeiten zu jeder der beiden 
Platten und deren liittelwerte über beide Platten sind für die 
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gegenwärtige Systendateiverteilung und für die durch Opti- 
nierung erreichte Systemdateiverteilung in der Tabelle 4 
angegeben. Daraus folgt eine Verkürzung der mittleren Posi- 
tionierzeit beider Platten un 4ıns. Bei einer Umrechnung 
über die Zahl der Systemplattenzugriffe für eine iießzeit 
von 12h ergibt das eine Verkürzung der Positionierzeit 

von insgesaut 47min. 
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Tabelle 1: Prozentuale Auslastung verschiedener festzugeordneter 
Ressourcen 


Geräteklasse 


Konfiguration 12 16 


Geräte | Geräte :. Geräte 


i Auslastung 


in % | 


“ absolute. absolute Zugriffszahl 
: Zugriffszahl Zylinderzahl 
SYS1.SYSJOBQE 
SYS1.SVCLIB 
SYS1.LINKLIB 
SYS1,.COMPILE 
SYS1.MRLINK 2 
SYS1.MANX 6 765 1 691 
SYS1.SORTLIB 3 812 953 
| SYS1.PLILIB 3 719 | 619 
: SYS1.SYSVLOGX 2 


SYS1.PL1OPT 
SYS1.LOGREL 

| SYS1.PROCLIB 
SYS1.1RPROC 


! 
| SYS1.COBLIB 
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Tebelle 3: Vergleich der ZugriffshHufigkeiten der Umverteilung 
mit den gegenwärtigen Zugriffshäufigkeiten 


Zugriffshäufigkeiten 
Platten- gegenwärtig optima 


absolut; relativ [absolut | relativ 


252 446 0,3576 362 630 0,5136 


29852 453 549 0,6424 1343 365 0,4864 | 


I I, ! 


705 995 1,5000 !705 995 | 1,0000 | 


Tabelle 4: Ergebnisse der Umverteilung 


T 


Plattenstapel mittlere Positionierzeit Tp [ms] 


| gegenwärtig : optimal 


DP9851 | 25,25 23,11 


| Dp9852 42,72 | 36,02 


I 9 | 36,18 32,5 | 
| REEL GENE GEEEEEEENEREER. EEE. 
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Bazewicz Mieczyszaw, Mika Teodor 


User conditions to software functions in distributed 
processing system /DPS/ 
5 
1. Introduction 


Research activities in universities, based upon more and more 
precise methods and calling therefore for more and more complex 
observations, are often carried on with the use of computer systems 
supporting not only calculations of scientific workers, but also 
data gathering, segregating end analyzing. Computer applications 
in the research process cause tasks to be solved by the computer 
system designers, concerning the selection of hardware and logical 
architecture being appropriater to research work. The hitherto 
unsolved problem is to develop methods of adapting computer £Kysten 
architecture to the needs of research works carried on in univer- 
sities. 

In our paper a method of software and hardware adapting to 
user needs will be presented of the computer user point of view, 
which. differs of the point of view of software and hardware pro- 
ducer or omer. The approaches to computer system adapting perfor- 
med up to now have ‚taked into consideration mainly the computer 
throughput and the maximal load during user job execution. Our 
approach differa of them in that the main criterion of configu- 
ration adapting is the best service of user, which requirements 
and needs result from specific functions in research activities 
proper to his concern. The other criteria fulfill only auxiliary 
rules such as boundaries, which should be exceed by designing new 
configurations based upon new technologies. 

Into our mainly consideration is the development .arising in 
technology. and system organization and its influence into the 


possibility to fulfill users requirements, From this result some 
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changes in methods of user system designing which are the second 
theme of our concern. 

In uniprocessor systems, architecture adapting was performed 
only within a limited scope, considering the type of hardware and 
the necessity to use complex program mechanisms protecting against 
mıtual interference. of- different calculation processes executed in 
parallel. Uniprocessor systems imposed, in turn, constraints con- 
Geniheueere requirements, _forcing the latter into the possibili- 
ties offered by uniprocessar. The problems of hardware and software 
choice, taking. into considerations users’ requirements without 
imposed constraints, can be more efficiently solved by designing, 
for those requirements, more sophisticated systems composed of many 
processors, such as local computer networks. 

So, the adaptation of computer system architecture to users’ 
requirements is a complex problem, as it depends upon many, dif- 
ferent factors: upon the characteristics of the user and his job, 
the requirements reffering to the method. of job processing, and 
it depends also upon the elements, which the computer system can 
be built from and the use of which. permits to fulfill the users’ 
requirements. 

The modern technologies provide the design .of multiprocessor 
systems, ‚remote networks and some medial solutions such 'as local 
area network /LAN/. 

The purpose. of multiprocessor systens is the increasing of / 
computer system performance.for such applications a5 tke coömputa- 
‚tions for weather - forecast. The. purpose of remote network is the 
increasing of access to large computer systens for users situated 
in’ wide space. The local area network has en elastic structure, 
which is suitable to satisfy user needs. 

Höw great importance have the new technologies proves the last 
IFIP conference in Florence /Italy/, where new technologies have 


been presented for local area network building. Among other, the’ 
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Advanced Micro Devices, Inc. has announced the introducing to the 
market some elements based on VLSI, complexly solving the building 
problems of local area networks. In that solution the local area 
network was divided into two subnetworks: the frontenäd network and 
the backend one. 

The frontend network serves to bind terminals to CPW’s, ‚and 
the backend network links the CPUs with high speed auxiliary 
nemories.” 

Different bit rates are required for both networks. The front- 
end node based on AMDelements is similar to Ethermet node and sup- 
port bit rates from 50 kbs to 200 kbs. The backend node support 
bit rates from 10ngbs to 1 gbs. This fulfill the ANSI recommenda- 
tion, which defines the necessary bit rate at a level of 50 mgt3, 
but this bit rate may not be justifiable in all networks. 

The high speed node for the backend network is a programable 
device, which requires about 70 chips, and process a protocol Zor 
"data exchange between large CPUs and high speed disks. 

In uniprocessor systems adapting the architecture to users’ 
requirements is restricted by the possibility of hardware selection. 
A certain freedom of choice was obtained only what concerns the j 
software, which, also, was restricted by the ‚hardware characteristics. 
In distributed systems more degrees of freedom exist when solving 
that problem. The choice concerns, indeeäd, depending on user’s 
requirements: 

- the number and kind of system processors, 

- the dedication of processors to determined user’s jobs, 

- the user’s job division into processes performed in differeut 
perts of a distributed computer systen. 

However, the choice of hardware and software elements in the 
case ‘of a higher number of degrees of freedom sets more complex 
problens for the designer. The choice of ar effective solution, 
from among a wide Sspecter of ihez, requires to state precisely the 


eriteria of system architecture adapting to users’ requirements, 
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the most obvious one being the criterion of power /performance/ 
balancing according to the requirements. 

An approach to such a method of solving the problem of adapting 
architecture to users’ requirements, based upon a univocal repre- 
sentation of the processes of a real object in a computer system 
architecture is the subject of this paper. The point of 'the- approach 
consists in trying to obtain, in designing, a possibly adequate 
representation of the environment by the system of servicing those 
requirements. That approach will be discussed upon an example of 


experiment planning and controlling in a university laboratory. 


2. A method of system architecture adapting to users’ requirements 


A number of trials of adapting distributed system architectures, 
namely the ICN /Interuniversity Computer Network/ architecture, to 
users’ requirements in universities for research work supporting, 
was Dresented 4 1]; The problem of developing an efficient method 
of distributed system designing is considered to be a problem of 
formılating relations between two vectors containing variables 
determining the information processes from the user's point of view, 
and variables describing the inner structure of the system assuring 
the required user services. 

The users’ requirements and the external environment constraints 
are described by tne vector X'= Kırkarores X) of primary varia- 
bles, tnis vector deteraining the user properties or services 
performed by the computer system. The X, variables concern: features 
and constraints of users, characteristics oT the job to be proces- 
sed, precision, reliability and secrecy, and other constraints 
imposed by tne environment, such as haräware and software availa- 
bility, financiai means, etc. 

The parameters of the system for users’ requirement servicing 
are described by tae vector Y = (1 Ygree ent ) of secondary varia- 
bles, that vector determininz tne. inner structure of. the computer 


systen. The 2 veriables concern logic structure of the system, 
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system nodes, routing, organization into subsystems and hardware 
end software elements. Those variables are grouped dependinz upon 
their influence on the system /full or partial influence on a par- 
tial influence on a particular element/, and upon subsysten activ- 
eness /data processing and transmission/. 

Each of the primary variables depends upon a number or all 
secondary variables, i.e. X, = x.v), where Y is the vector of 
some or of all secondary variables. In order to evaluate the 
solutions obtained in the design symthesis process, the variables 
of a performance or evaluation vector P = (BenPgsesesB)» are 


introduced, where the P, variables, for i = 1,...,5 are e.g. 


waiting time, error IN etc. The evaluation basis is the user job 
handling process, and the evaluation criterion is efficiency, job 
handling mean time. That evaluation permitted to prove the useful- 
ness of the method for selecting the organization and number of 
nodes in the communications subnet, 

The method has, however, another significance and importance 
in the case of Local Computer Networks /LCN/, where the nodes have 


a different destination and where there is no communications subnet. 


3. Laboratory environment of Local Computer Network 


The problem of computer systen architecture adapting to user 
requirements will be presented, considering 15 existing. important 
laboratories at the Technical University of iirociaw. Some of those 
laboratories are equipped with minicomputer systems connected 
trough module systems of measuring and control automation units 
of the CAKMAC type to the experimental object. In such a laboratory 
autematie collection of measuring data of an experiment carried 
out can be performed, as well as a relatively simple processing - 
of those data in order to determine ihe character of the experi- 
ment and to verify the hipotheses formılated by the experiment 
goal. In practice, the laboratory experiment includes not only 


experiment control, measuring and analysis of measurement data, 


‚ 
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but also the process.of experiment planning, taking into conside- 
ration the results and conclusions from the previous experiments 
carried out. Thus, a computer syStem supporting experiment planning 
and control should permit to store data and results from previous 
experiments in the form of an experimental data base, It is not 
possible on, ecönomice grounds, to equip every laboratory with such 
computer systems, so the solution of the problen of architecture 
design is based upon computer network. 

Let us nearly examine the processes of experiment planning and. 
Tunning in a university laboratory, considering the case of a 
mechanical laboratory [2]. The following typical processes, for 
experiments in different domains of research, can be isolated from 
among all experiment planning and running processes in a university 
research laboratory: 

Pi. Setting the measuring equipment, consisting in determining the 
measuring range -and calibrating measuring instruments. That process 
is ‚generally hand performed, although it can be computer supported 
when setting up the initial values /e.g. zero setting/ of instruments 
by means of CAMAC channels. | 

P2. Setting up external conditions forcing the required behaviour 
of the experiment object. Those conditions are for example en 
appropriate value opening or closing in chemical experiments, or 
applying an exciting force in strength experiments. 

P3. Heasurenment data input through measuring systems /indicators, 
signal converters etc..../ in a determined time interval for 
dynamic experiments, or on the basis of N-tuple measurements in 
static experiments. 

P4. Preparatory processing of the measurement data by assigning 
suitable physical välues to electrical values obtained by measu- 
ring ,„ and calculating means. values of a series of measurements, 
and the standard devietions or variences. 

P5. Pre-evaluating the obtained measurement data, i.e. evaluating 
the likelihood, e.g. by comparing the standard deviations with the 


maximum set value. That evaluation permits to eliminate the 
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so-called "big" errors consisting in data input from a measuring 
point out of salibration or a broken dom one. 

P6. Measurement data processing according to a model formulated by 
the experimenter, and obtaining in this way the basic relations 
existing in the experiment, e.g. in the form of coefficients of 
determined linear function, exponential function, etc. 

P7. Gomparing the obtained results with data concerning experiments 
previously carried out and stored in the data base. Decision making 
concerning model change or experiment repetition under other 
external conditions. 

P8. Dialogue carrying on with the user, who forces the beginning 

of the particular experiment phases, who is informed on partial 
results, and who makes decisions concerning the directions of 
experiment running or the method of measurement result analysis. 

The user signals the beginning of processes P2 and P3, and he 
is informed by processes P5 and P8 about evaluation results on the 
basis of which he signals again the beginning of measurements. The 
user decides also about the selection, of the model or relations 
used in process P6, and about running the whole experiment, by 
changing the external conditions or the disposition of measuring 
points. 

Process P2 should be performed, especially for dynamic 
experiments requiring to control the external conditions in a 
closed lopp, by a very fast control system, thus by a control 
system or simple processor which permits to produce and to emit 
control signals within a short time. 

Process P3 should be performed, for a high number of measuring 
points, in a Processor with wide possibilities of multiplying ways 
of data collection. 

Process P4 should be performed in a processor permitting to 
execute fast, sinple celculations on a wide quantity of data. 

Process P5 can be performed in a simple processor, i.e. a 
processor permitting to execute simple calculations on a somewhat 
less number of data, /than in process P4. 
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In order to perform process P6, a processor with higher 
conputing power is required for executing somewhat more complex 
calculations, but on aggregated data, thus on a smaller number of 
data. 

For performing process P7, mass Stores are necessary to store 
in a suitable data base an important as possible number of experi- 
mental data, serving as standard data for further experiments. 

Process P8 requires a processor with terminal devices for 
terrying on dialogue. 

For each of the discussed processes 'a processor with different 
characteristics is required, and it can be pre-assumed that a 
special processor will be assigned to each process, each processor 
being the best adapted on to its om process. As there is a need 
for transmitting information from one process to another one, the 
mentioned special processorsg should be interconnected, and as they 
should be processors with different possibilities, those connect- 
tions should form a computer network. The small separation of the 
particuler processors makes it possible to design a local computer 
network. 

However, the need, for obtaining the automation of the whole 
laboratory complex, with economically grounded restrictions,causes 
the distributed system should be designed in such a way that more 
developed processors should not be multiplied in all laboratories 
/such elements developing the system being mass stores for,\process 
P7 and a set of terminal devices for user-system dialogue in 
process P&/. Thus, it is intended to connect all the simpler pro- 
cessors perfoming processes Pl -— Pö6ö into a local computer network, 


and to .utilize the ICN computers as more developed Systeuns. 


4. Laboratory ICN configuration 


On the basis of the above - mentioned process analysis, 
without considering the restrictions imposeä by interprocessor 


communication, the conclusion arise, that a local computer network 
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destined for laboratory experiment planning and running should be 
of the star architecture where, in the center the systen D is 
located for the dialogue with the user, system D being connected 
with system E, in which information is stored in the base of 
experimental data. At the. end of the rays of the star the proces- 
Sors °, with systems of CAMAC type measuring and control automation 
are located, with ceircuits multiplying the measuring ways. Each 
laboratory should be equipped with such systems. Systems D and E 
ere connected to the Interuniversity Computer Network, considering 
they have to be big systems permitting to perform, beside processes 
for experiment planning and running, many other tasks concerning 
scientific research in the university. Moreover, the separation of 
both these systens can be importent, as the processes being per- 
formed are relatively slow, but big size auxillary store are needed. 

Between system D, where process P8 is performed, and systens 
c performing the fundamental control end measuring processes P2 
and P3 processors A,ser.„B,, performing processes P4 to P6 are 
located. 

Ifa separate processor is assigned to each of the pracesses 
P4 to P6, such processor being the best adapted one to the parti- 
cular process, a full suitability of the architecture of many pro- 
cesses and many processors is obtained, that suitability being 
called homomorphism by Jensen [3]. However, the requirements of 
the neighbor processors, although different, are sonewhat similar, 
e.g. for performing processes P4 and P5 the processors should fast 
sxecute relatively simple calculations, thus both these processes 
can be installed in a single processor, the more so that the »ro- 
cesses are consecutively performed. Two other processors A, and B, 
have been decided to be applied between system D and systens 6; 
as a result of analysis of the whole of experiment control proces- 
ses considerinz the 3 following eriteria: 
- adapting the processor performance, 
- assuring an appropriate response time gf different processors, 
- minimizing the information volume being transmiiteäd fron a 


process to the next one. 
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5. Some selection criteria 


‚Requirements eoncerning. conputing power have been discussed 
in point 3. It can be noted that the processing performance for 
that application was growing for the consecutive processes. Thus a 
suggestion arose to Consider a star architecture, where, in the 
center, the system with, the greatest performance would be located, 
and in the star rays — the most simple processors. 

The response times for a complex application such as. experiment 
control should be different for different stages 'of that applica- 
tion. Here a time can be considered which goes by from receiving a 
signal indicating that a physical conäition has the value X- AX 
to the instant of emitting a control signal serving to correct the 
value AX to kevel X. So, it is the response tine of the control 
syStem performing process P2. Another response time is the time 
which goes by from the beginning of measuring in process P3 to 
receiving a pre-evaluation of measurement results, obtained from 
process P5. A reduction of that response time can be achieved by ı 
integrating the performing of processes P}, P4,and P5 in a single, 
bigger system. That fact is one of the arguments against the intro- 
duction of a full homomorphism into a’ distributeä system. 

A third response time, nearer to the response times in stan- 
dard time-sharing systems, is the dialogue response time /process 
P8/ measured e.g. from the instant of model describing to the 
instant of obtaining the basic relations in process P6. 

All the above responses are required after a lapsee of dif- 
ferent times. The first time, for fast physical and chemical. pro- 
cesses, shoulä not exceed a few nicroseconds. The second time 
depends upon the veldcity of. the process itself in the case of a 
dynamic experiment. However, as in that time the decision is made 
on experiment’ repeating, the time should be fractions of a second. 
The thirä response time can be of an order of even a couple of 
seconds, but that does not interfere with the possibility of 
obtaining that time from a systen connected by a terminal to a 


remote network. 
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Between processes Pi - P8 different information is exchanged. 
From process P3 to process P4 a matrix N x N is transmitted, where 
N indicates the number of repeated measuring or the number of time 
interval division of the experiment into instants in which the 
measurements are executed, and M indicates the number of dirferent 
measuring points. From processes P4 to processes P5 two or four 
vectors with length M are transmitted, these vectors including 
means, varlances or standard deviations, and, sometimes also 
values of maximum and minimum quantities. The same vectors are 
transmitted to processes P6 which performs the processing of the 
data vectors obtained from P3, but on the ground of information 
/nodel form/ from process P7 storing experimental data files. The 
data of the running experiment are transmitted to those experimen- 
tal.data, between processes P6 and P7. 


6. Conclusions 


As a result of such analysis, we can demonstrate that some 
similar processes may be performed in a single systen. We obtain, 
in the same way, a less information volume flow between different 
processors, and not increased system response time. The architec- 
ture adapting of a distributed system /LCN/ to real’system require- 
ments, as in the example of the above discussed experiment control 
system, cannot be achieveä only by a logical decomposition of the 
whole process into simpler, sufficiently different subprocesses 
from the point of view of their properties, and next by the struc- 
tural correspondence according to the homomorphism principle of 
process to processor structures, although that allows to obtain a 
short response time [4]. Taking into consideration the system 
performance, system response time and Folima of exchanged informa- 
tion, by architecture selecting to user requirements, is indispen- 
sable for design with reäundance avoiding and definition: of some 
specific rules of information exchange and the kind of synchroni- 
zation between the ICN nodes, 
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The method presented in point 2, may be therefore applied not 
only onto the communication field [1], but also in processidg 
aspects onto ILCN, and the vectors: X - of user’requirements, Y - of 
syBtem inner structure, and P - of selection triterion, allow to. 


1 1 R 
determine the dependence X=x(Y) in processing element space. 


References: 


[1] Bazewicz M., Pufman J., The Role of User Job Handling Process 
in the Computer Network. Design Methods. Working Papers of 
COMNET’81. May 81. Budapest. 

[2] Kasprzak W., Lysik B., Computer System in a Research laboratory 
/in Polish/, Technical University of \iroczaw, 1981. 

(3] Jensen E.D., The Honeywell Experimental Distributed Processors 
- An Overview. Computer. Jan. 1978. 

[4] Peberdy N.J., Distributed Computer Systems - A Review, 
Questiones Informaticae, V. 1, No 1, 1979. 


Verfassers: 


Doz.Dr.Ing. Hieczysiaw Bazewicz 

Dipl.math. Teodor Mika 

Technicai University of Wroctaw, Poland 
Institute of Control and Systems Engineering 
50-370 “roctaw 

üybrzeze Wyspianskiego 27 


136 


Heymer, Volker 


Tendenzen_ der_ „Davenkommunskatıon. 


1. _Einl2itung ” ; 
Die elektronische Informationsverarbeitung hat sich: 'jin 

allen Bereichen ‚der Volkswirtschaft einen festen "Platz er- 
obert, Sj’e ist ein integraler Bestandteil in Leitung und 
Plafung, zntwicklung und Praduktion geworden, 

Durch die breite Einfuehrung von Mikroelektronik und Roboter- 
technik erweitert sich ihr Anwendungsgebiet betraechtlich, -. : 
der ‚Frage des Zugriffes zu’ EN SSIELemen und ihrer Standort- 
bestimmung kommt unter ‚dem Gesichtspunkt einer effektiven 
Nutzung. der 'Rechenkapazitaet eine grosse Bedeutung zu, Die 
gegenwaertige Situation ist dadurch charakterisiert; dass 

der Nutzer seine Aufgaben zum Rechner bringen muss (Abb, 1a) 
bzw. ‘ueber Terminals fest mit einem bestimmten EDV-System 
verbunden ist (Abb, 1b). 


‚Abb, tas Klassischer Zugriff zu EDV«-Systemen 
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Abt, 1b; Zugriff zu EDV-Systemen ueber lokale und 
entfernte Terminals 


Obwohl der zweite Fall fuer den Nutzer eine deutliche 
Verbesserung seiner Zugriffsbedingungen schafft, bleiben 
‘zwei Probleme offen; 

- der Zugriff des Nutzers zu anderen Rechenanlagen, die 
aufgrund von Spezialressourcen einschliesslich Programn- 
bibliotheken fuer bestimmte’ Aufgaben besser geeignet 
sind als die eigene Rechenanlage und 

- die geringe Ausnutzung der verwendeten Verbindungsleitun- 
gen und damit die oekonomisch bedingte Unmoeglichkeit der 
Bereitstellung dieser Art des Zugriffs zu EDV-Systemen " 
fuer jede Anforderung. 


Die Loesung fuer diese Probleme liest in Analogie zur 
vergleichlsaren Situation bei der Energieverteilung oder 
im Fernsprechnetz in der Schaffung von Verbundsystenen, 
Daten= und Rechnernetzen (Aba. 2), an denen gegenwaertig 
international in grosser 3reite gearbeitet wird, 
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:EDV - Systene 


Datenbanken 


Datennetz 
- zweigspezifisch 
- Öffentlich 
- national 
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Abb. 2; Verbund von EDV=Systemen und Terminals ueber ein 
Datennetz mit standardisierten Schnittstellen 


2. Internationale Situation auf dem Gebiet der Daten- 
kommunikation 


Die Entwicklung der elektronischen Informationsverarbeitung 
wird gegenwaertig durch zwei Faktoren besonders beeinflusst, 


Der. erste Faktor ist die Mikroelektronik. Durch sie wird 

‚eine bedeutende Kostenreduzierung auf dem Hardware-Sektor 
erreicht, Damit werden die oekonomischen Voraussetzungen 
geschaffen, um die Informationsverarbeitung in neuen 3ereichen 
anzuwenden, 

Der zweite Faktor ist die Verbindung von EDV=-Systemen und 
Telekommunikationssystemen, Dadurch wurde .einerseits der- 
entfernte Zugriff zu Rechenanlagen und deren Verkopplung 
moeglich und andererseits wurden durch den Einsatz von 
Mitteln der Rechentechnik in der Nachrichtentechnik neue 
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Uebertragungsverfahren entwickelt und eine Leistungsstei- 
gerung erreicht, die die Voraussetzung fuer die Verkopp- 
lung von Rechnern und Terminals zu Rechnernetzen ist, 


Moderne Rechnersysteme erbringen eine hohe Verarbeitungs- 
‚teistung und verfuegen ueber Massenspeicher, auf deren 
Basis umfassende Informationssysteme aufgebaut werden 
koennen, Datennetze sind die dazu erforderlichen Trans- 
portsysteme, um diese Leistungen zum Nutzer zu bringen 
bzw. die Daten zu sammeln und zu verteilen, 

Durch die Mikroelektronik werden billige Rechnerleistung 
bzw, Steuerkapazitaeten, an den Einzelarbeitsplatz des 
Wissenschaftlers, Ingenieurs, oder Produktionsarbeiters 
gebracht. Deren Arbeit ist im wachsenden Masse durch 
Kooperation oder Verflechtung mit der Arbeit anderer 
gekennzeichnet, ‚Die dazu erforderliche Verbindung der 
‚einzelnen Rechner- bzw. Steuersysteme wird mit Mitteln 
der Rechnerkommunikation realisiert, 

Eine quantitative Erfassung dieser Situation fuer West- 
europa wurde mit der Eurodata'79 - Studie /EUR79/ 


\ 


Software-Entwicklung 11 
wniss.techn. Berechnungen 17 
Zugriff zu Datenbanken 
Mensch-Mensch-Kommunikation 18 
Allg. Leitung/Verwaltung 39 
" Bankwesen 30 


Buchungssystenme 3,1 
Börse 17 
Zugriff. zu Patientendaten 


‚andere 


Abt.‘ 35 Hauptanwendungen der Datenkommunikation in 
Westeuropa - Eurodata'!79 - Studie 
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versucht, in der 141000 Zugriffspunkte zu Informations- 
verarbeitungssystemen ueber Datenkommunikation in 17 
Laendern bewertet wurden (Abb, 3). 

Waehrend zu Beginn der Rechnernetzentwicklung die Anwendun- 
gen Software-Entwicklung, wissenschaftlich-technischen , 
Berechnungen und Buchungssysteme dominierten, ist aus der Ab- 
bildung eine noch jetzt anhaltende Tendenz zur raschen Zunahme 
der Anwendungsfaelle auf den Gebieten der Leitung/Verwaltung, 
der Geldwirtschaft und der Mensch-Mensch-Kommunikation 

zu entnehnen, 

Die. spuerbaren oekonomischen Vorteile, die sich aus dem 
Einsatz der Datenkommunikation ergeben haben, fuehrten dazu, 
dass nach Rechnernetzen, die vorwiegend im Bereich der 
Forschung eingesetzt wurden und selbst Gegenstand der 
Rechnernetzforschung waren, wie das amerikanische ARPANET 
/MCWA77/ und das franzoesische CYCLADES /POU73/, bald 

erste zweigspezifische und dann auch oeffentliche Daten- 
netze und Rechnernetze auf kommerzieller Basis Rechner- 
kommunikationsdienste anboten, 

Auf dem Gebiet der oeffentlichen Datennetze ist dabei 
besonders das Paketvermittlungsnetz PSS (Packet Switch 
Service) /MED80/ der Britischen Post hervorzuheben (Abt,4). 
Die Britische Post spielte und spielt eine Pionierrolle 
unter den Nachrichtenverwaltungen auf dem Gebiet der 
Datenkommunikation und deren-Anwendung fuer neue Dienste, 

So ist das System PRESTEL /CHI81/ der Prototyp fuer den 
neuen Telekommunikationsdienst VIDEOTEX, der von der CCITT 
empfohlen wird, Er stellt durcn Kombination von Fernseh- 
geraet und Telefonanschluss unter Ausnutzung der Rechner- 
netztechnologie Dienste bereit, die neben dem Einsatz in 
der Industrie, ein breites Spektrum der Anwendung von 
Datenbanken und Rechnersystemen fuer solche Bereiche der 
Volkswirtschaft, wie Dienstleistungen, Handel und Handwerk 
sowie fuer Haushalt und Freizeitgestaltuns ermoeglichen 
[SERAB2/. 
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Abb,4; Das Paketvermittlungsnetz PSS der Britischen Post. 
in der Ausbaustufe 1981 


In den sozialistischen Laendern lag der Schwerpunkt der 
Arbeiten zu Rechnernetzen im Bereich der Akademien der 
Wissenschaften, In den Rechnernetzen DELTA (s, Pkt. 4), 
CEKOFI /MJA78/ und dem Experimentellen Rechnernetz der 
AdW der Lettischen SSR /YAK78, KIK82/ (Abb, 5) ist die 
entfernte Auftragsbearbeitung die Hauptanwendung. 

Die Arbeiten wurden von den Rechnerherstellern aufge- 
griffen, Ein erstes kommerzielles System liegt mit dem 
'Rechnernetz VNS /RAJ81/. vor. An ein Paketvermittlungssub- 
netz sind hier Terminals und Rechnersysteme auf denen sich 
‚Datenbanken befinden, angeschlossen, Dabei kann von einem 
beliebigen Terminal zu einer beliebigen Datenbank zuge- 
sriffen werden und die Terminals,koennen untereinander 
kommunizieren (Abb, 6). 
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Abb, 5s Experimentelles Rechnernetz der AdW der 
Lettischen SSR 


Abb, 6s Videoton Network System VNS 
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Die wachsende Anwendung der Rechnernetztechnologie hat 

dazu gefuehrt, dass Datennetze üeber die Laendergrenzen 

hinaus erweitert wurden, wie die amerikanischen Netze 

TELENET und TYMNET, und in starkem Masse an internationalen 

Standards gearbeitet wird. 

Die Standardisierungsarbeiten konzentrieren sich .. 

- im Subkomittee 16 des Technischen Komittees 97 der 
Internationalen Organisation fuer Standardisierung 
(ISO/TC97/SC16) 

- in der Studiengruppe VII des. Internationalen Konsul=- 
tativkomittees fuer Telephonie und Telegraphie 
(CCITT/Study Group VII) 

- in der Gemeinsamen Spezialistensektion Rechnernetze des 
ESER und SKR (GSS RN) und 

- jm Technischen Komittee 6 der Internationalen fossdszatten 
fuer Informationsverarbteitung (IFIP/TC6). 


da. Rechnernetzarchitektur = „Verkopplung, offener Sys teme 


Allgemeine Prinzipien zum, Verbund von Rechnersystemen zu 
Rechnernetzen sind von der ISO im Dokument IlData Processing 
Open Systens Interconnection - Basic Reference Modelll 
/TS07498/ (OSI-Model1) fixiert, 

Dieser Internationale Standard schafft den Rahnen fuer die 
Koordination von existierenden und zukuenftigen Standards 
zur Verkopplung von Systemen, Unter einem System werden 
dabei eine oder mehrere EDVA, die entsprechenden Programne, 
peripheren Geraete, Terminals, Bediener, Prozesse, Infor- 
mationsuebertragungseinrichtungen usw. verstanden, die ein 
autonomes Ganzes bilden, das Informationen verarbeiten 
und/oder uebertragen kann. Ein solches System wird als 
lloffen!! bezeichnet, wenn es die entsprechenden Standards 
zur Kommunikation mit anderen Systemen anwendet, 

Als Uebertragungsmedien werden Telekommunikationsmedien 
vorausgesetzt. 5x 
Das OSI-Modell beinhaltet nur Probleme der Kooperation 
zwischen den Systemen und nicht die interne Struktur 

und. Funktionsweise der einzelnen Systene. 
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Aufbauend auf Erkenntnissen zur Struktur von Rechnersystemen 
und den Erfahrungen aus der Entwicklung experimenteller 
Rechnernetze wurde die in Abb, 7 dargestellte Schichten- 
architektur ausgearbeitet, 


Protokolle 


— 


I 


Abb. 7s 0SI-Schichtenmodell zur Verkopplung offener 
Systeme 


Sie stellt ein hierarchisches System von ‘Schichten dar, 
in dem die (n)-Schicht der (n+1)-Schicht einen (n)-Dienst 
bereitstellt und dazu den (n-1)-Dienst der (n-1)-Schicht 
in Anspruch nimnt, 


Die (n-1)-Schicht besteht aus Subsystemen des gleichen 
Niveaus in den verkoppelten Systemen. 

Der (n)-Dienst wird von (n)-entities der (n)-Schicht 
bereitgestellt. Sie arbeiten dazu nach dem (n)-Protokoll 
zusammen. Ein Protokoll ist ein Satz von Regeln und For- 
maten (Semantik und Syntax), der die Kommunikation zwischen 
den (n)-entities bestimnt. 


Das Zusammenwirken der entities ist in Abb, 8 dargestellt. 
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'(a+1)-Schicht 


(n+1)-entity 


(n+1)-entity 


(n)-connection- 
'endpoint-identifier 


(n)-service- 
access-point 


Bun 2 


(n)-Schicht 


N 
(n)-connection 


Abb, 85 Zusammenwirken von entities im OSI-Modell 


Die (n+1)-entities nehnen ueber (n)-service-access-points 
den Dienst der (n)-Schicht in Anspruch, Ein (n+1)-entity 
wird seinem entsprechenden (n)-entity durch die (n)-address 
zugeordnet, Zur Abwicklung der Kommunikation zwischen den 
(n+1)-entities wird durch die (n)-Schicht eine (n)-connec- 
tion aufgebaut. Der lokale Identifikator, mit dem ein 
(n+1)-entity die «(n)-connection identifizieren kann, ist der 
(n)-connection-endpoint-identifier, 


Zur Illustration '!st der Ablauf einer Uebertragung in Abt, 9 
dargestellt, 


Die Nachrichten zur Realisierung des Protokolls werden 
logisch jeweils ueber eine Verbindung (connection) ausge- 
tauscht (Rahmenpfeile), 
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Sonder Enpfünger 
Protokoll. 


Abb. 9: Ablauf einer Nachrichtenuebertragung 


[4 
Der reale Transport der Informationen in Form von Bitfolgen 
vollzieht sich dagegen im Sendersystem ueber alle 7 Schichten 
bis zum physischen’ Uebertragungsmedium, wird zum Empfaenger- 
system uebertragen und dort von Schicht zu Schicht nach oben 
gegeben (volle Pfeile). Dabei wird in der jeweiligen Schicht 
die logische Uebertragung ueber die Verbindung abgeschlossen. 


Die oberste Schicht ist die Anwendungsschicht, Sie besteht 
aus den kooperierenden Anwendungskomponenten, Die unteren 
Schichten stellen stufenweise Kommunikationsdienste einer 
jeweils hoeheren Qualitaet bereit, durch die die Anwendungs- 
komponenten ihre Kooperation abwickeln, 
Die Schnittstelle zwischen zwei Schichten entspricht dem 
Qualitaetsuebergang und ist in 0OSI-Dienststandards (Service 
Definition) definiert. Die Arbeit innerhalb der Schichten 
wird durch OSI-Protokollstandards (Protocol Specification) 
geregelt. 
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Die einzelnen Schichten lassen sich folgendermassen kurz h) 
charakterisieren; 
Application - Die Anwendungsschicht dient als Tor 


zwischen kommunizierenden Nutzern, durch 
das der Austausch von Informationen 
erfolgt, 


Presentation - Die Darstellungsschicht stellt die 
Informationen gegenueber den kommu- 
nizierenden Anwendungskomponenten 
so dar, dass die Bedeutung erhalten 
bleibt, waehrend syntaktische Unter- 
schiede ausgeglichen werden. 


Session - Die Sitzungsschicht liefert die 
fuer die kooperierenden Darstellungs- 
komponenten erforderlichen Mittel zur 
Organisation und Synchrönisation 
ihrer Zusammenarbeit und zur Durch- 
fuehrung des Datenaustauschs, 


Transport - Die Transportschicht gewaehrleistet 
eine transparente Datenuebertragung 
zwischen Sitzungskomponenten und 
sichert, dass diese zuverlaessig 
‘und kosteneffektiv ablaeuft.\ 


Network - Die Netzschicht stelit Mittel zum 
Aufbau, Betrieb und Abbau von Netz- 
verbindungen ‚zwischen OSI-Systemen 

\ 


bereit, 
Data Link - Die Verbindungsschicht fuehrt die 
Aktivierung, den Betrieb und die N 


Deaktivierung von Datenverbindungen 
durch und entdeckt und korrigiert, 
wenn moeglich, Fehler der physischen 
Schicht, 
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Physical - Die physische Schicht enthaelt die 
mechanischen, elektrischen, funktio- 
nellen und prozedurellen Mittel fuer 
die Aktivierung, den Betrieb und die 
Deaktivierung von physischen Ver- 
bindungen zur Bit-Uebertragung zwischen 
Verbindungskomponenten, 


4. Rechnernetzdienste und Anwendungsgebiete im Rechnernetz 


Das Rechnernetz fuer Forschung und Lehre DELTA /MEI81/, 
dass im Zentrum fuer Rechentechnik der AdW der DDR und. im 
Rechenzentrum der TU Dresden entwickelt wurde, entspricht 
in seiner Systemarchitektur (Abb. 10) dem OSI-Modell zur 
Verkopplung offener Systene, 


OK MAIL FKD RJE 


Application 2 'oKp x A 
| rerontarion 
Br 


Network 


Physical 


Abb, 105 Architekturmodell des Rechnernetzes DELTA 
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Die unteren vier Kommunikationsdienste sind einheitlich 
fuer alle Anwendungen realisiert. Ihre Protokolle wurden 
unter Beruecksichtigung der internationalen Diskussionen 
selbst entwickelt. Entsprechend der Verabschiedung der 
Standardprotokollempfehlungen der CCITT und ISO (z.B, /X.25, 
IS0861/) erfolgt die schrittweise Einfuehrung der neuen 
Protokolle, 


Die oberen drei Schichten sind fuer jede der Anwendungen 
spezifisch entwickelt worden, Damit konnten der Umfang 

der entsprechenden Dienste auf die Erfordernisse der je- 
weiligen Anwendung beschraenkt werden und die bei der auf- 
einanderfolgenden Entwicklung gewonnenen. Erkenntnisse sofort 
genutzt werden, Darueber hinaus wurde damit auf einfache 
Weise gewaehrleistet, dass nur die Softwarekomponenten der 
jeweils aktiven Anwendungen im Hauptspeicher der Rechner- 
systeme geladen sind, ; 
Das bedeutete aber auch, dass fuer jede Anwendung fuer alle 
drei Schichten jeweils spezifische Protokolle entwickelt 
werden mussten. 


Das Rechnernetz DELTA besteht aus dem Paketvermittlungsnetz 
KOMET /HAM80/ an das Verarbeitungsrechner vom Typ BESM6 

und ESER angeschlossen sind und einem Terminalnetz ueber 

das mit KRS4201-Stapelterminals zu den Verarbeitungsrechnern 
zugegriffen werden kann (Abt. 11), \ 
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BESK& 


Abb, 113 Komponenten des Rechnernetzes DELTA 


Im Rechnernetz DELTA werden z. 2. vier Nutzerdienste 
bereitgestellt, mit denen'die gegenwaertigen Anforderungen 
der Nutzer aus der AdW der DDR, der AdL der DDR und dem 
Hochschulwesen befriedigt werden koennen, 

Der Filekopierdienst ermoeglicht die Usbertragung von 
Files zwischen den Verarbeitungsrechnern, Die ESER=-Rechner 
und BESM=Rechner untereinander koennen Files beliebiger 
Struktur austauschen. Die Uebertragung zwischen ESER- 

und BEStli-Rechnern ist auf sequentielle Files beschraenkt, 


Die Entfernte Auftragsbearbeitung realisiert die Verar- 
‚beitung von Stapeljobs an einem von der Ein-/Ausgabe unter- 
schiedlichen Ort. Speziell kann fuer BESM-Jobs die Ein-/ 
Ausgabe ueber Stapelterminals auf der Basis des Kleinrech- 
ners KRS4201 erfolgen, 


Der Najlbox-Dienst, als Beispiel einer neuen Form der Tele- 
kommunikation, ermoeglicht das Formulieren von Briefen, deren 
Uebertragung zum Rechnersystem, auf dem sich die Kailbox 
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(Briefkasten) des Enpfaengers befindet, , und die Ablage in 
dieser Mailbox, Von dort kann der Empfaenger seine Briefe 
zu einen beliebigen Zeitpunkt abrufen, _ 


Als vierter Dienst wird eine Gruppe von Einfachen Daten- 
kommunikationsformen bereitgestellt, mit deren Hilfe inner- 
halt des Paketvermittlungsnetzes KOMET Telegramme ueber- 
mittelt und Lochstreifen uebertragen werden koennen, die 
Bediener der Verarbeitungsrechner ueber die Bedienkonsolen 
miteinänder im Dialog kommunizieren koennen und die Nutzer 
an den Stapelterminals untereinander einen Dialog fuehren 
koennen, 


Die. gegenwaertigen Anwendungsgebiete dieser Dienste, 
entsprechend-der in Pkt. 2 zitierten Eurodata'79-Studie, 
sind in Abb, 12 dargestellt, “ 


Zugriff su DB 


Eonsch-Kannch-Korn, 


Leitung/Verwaltung 
Bankwesen 
Buchungssystene 
Patientendaten 
andere 


Abb, 125 Anwendungsgebiete der Nutzerdienste des 
Rechnernetzes DELTA 


Sie entsprechen dem Charakter der wissenschaftlichen 
Einrichtungen, die ins Netz integriert sind, Die Dienste 
sind auch fuer andere -Anwendungsgetiete, die sich beim 
Einsatz der Rechnernetztechnologie in anderen Bereichen 
der Volkswirtschaft ergeben, geeignet, 
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'Schreiter, Guenter 


| Modulare Struktur eines Steuerprogrammes fuer einen freipro- 
grammierbaren Steuerrechner 


1; Einleitung 


Aufgrund sehr schnell wachsender Anforderungen und neuer An-' 
wendungen haben sich freiprogrammierbare Steuerrechner in 
Datenuebertragungsnetzen international schnell durchgesetzt, 
Die freie programmierbarkeit bietet folgende wesentliche 
Vorteile: 


- Leichte Anpassung des DV-Systems an neue Geraetetypen oder 
UVebertragungsprozeduren ohne Aenderung der Geraetetechnik, 

- Entlastung. des Verarbeitungsrechners hinsichtlich Verarbei 
tungszeit und Speicherkapazitaet sowie ; 

- guenstige Erweiterung des DV-Systems bei neuen Anwendungen, 
z.B, ‚Rechnemetze. i 


2. Einordnung von Steuerrechnern in das E/A-System eines Ver 
arbeitungsrechners N 


Die Ein- und Ausgabe von Daten ist stets Bestandteil des E/A 
Systems einer EDVA, Das E/A-System der Datenfernverarbeitung 
(DFV) von ESER-EDVA ist durch selbstaendige Funktionseinhei- 
ten in mehreren Ebenen und mit zentraler Steuerung reali- 
siert. ES besteht aus den Ebenen der 


- Zentraleinheiten (7E), 

- Kanalsteuereinheiten (KSE), 

- Gerastesteuereinheiten (GSE) fuer DFV und 
-.Datenendeinrichtungen (DEE). | 


L- — 
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Der Begriff Datenendeinriohtung (im ESER: Abonnentenpunkte) 
ist sehr weit gefasst, Es kann sich dabei sowohl um ein ein- 
faches E/A-Geraet als auch um eine Rechenanlage handeln, 

DEE koennen entweder direkt oder indirekt ueber ein Daten- 
uebertragungssystem an die GSE angeschloßSsen werden, Zwi=-. 
schen GSE und DEE koennen auoh weitere Funktionseinheiten 
zwischengeschaltet sein, 

Der Kleinrechner R 4201 kann bei entsprechender Konfigura- ’ 
tion als Steuerrechner parallel zusammenarbeiten mit 


- einer lokal: angeschlossenen .ESER=-EDVA und mehreren entfernt 
angeschlossenen Verarbeitungsrechnern (VR) sowie 
- mehreren lokal und entfernt angeschlossenen DEE, 


Die Summe aller anschliessbaren Leitungen betraegt 15 und ist 
durch die max. Anzahl der Anschlussteuereinheiten (AS) und 
die Nutzung der Eohtzeituhr els Zeitgeber begrenzt. Sollen 
mehr als 15 DEE bedient werden, sind Leitungskonzentratoren 
erforderlich, 

Der lokale Anschluss an die ESER-EDVA kann nur ueber den Mul- 
. tiplexkanal,erfolgen. Ueber max, 12 Subkanaele lassen sich 

12 Leitungen bedienen, i e 

Beim Anschluss an einen entfernt aufgestellten VR sind Ab=- 
sprachen erforderlich ueber die 


- physikalische Schnittstelle (funktionelle, elektrische und 
mechanische Eigenschaften) und 
- logische Schnittstelle (Datenuebertragungsprozedur). 


Der R 4201 ist somit geeignet fuer unterschiedliche kinsatz- 
faelle in der DFV (Bild 1), 
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y £, 
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Bild 1: Einsatzmöglichkeiten des R%201 im ESER, Reiho 1 


lokal oder entfernt aufgestelltes Multiplexsteuergeraet 
fuer DFV (MPD), 
Leitungskonzentrator, ı. 
- Vermittlungsrechner, 
Abohnentenpunkt und 

Terminalsteuerrechner., 


Trotz unterschiedlicher Einsatzmoeglichkeiten im k/A-System 
sind aus der Sicht der Steuerung die Aufgaben des Rechners 
die gleichen: 


- lokaler und entfernter Anschluss an den Verarbeitungsrechner, 
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Steuerung von DEE ueber verschiedene Typen von Vebertra- 
gungsleitungen mit unterschiedlichen physikalischen Schnitt- 
stellen und Geschwindigkeiten, 
Kode= und Schnittstellenwandlung, 
Zwischenpufferung der Daten, 

- Fehlererkennung auf den UVebertragungsleitungen und kinlei- 
tung von Nassnahmen zur Fehlerbehandlung.. 


Darueberhinaus besteht die Moeglichkeit der effektiveren 
Nutzung des VR, z.B; durch 


; Zußammenärbeit mit mehreren Verarbeitungsrechnern und mit 
unterschiediichen Rechnerarchitekturen, 
lokale uhd entfernte Datenein- ünd Ausgabe, 
Realisierung kundenspezifischer Anforderungen, 
Arbeit mit mehreren Zugriffsmethioden, einschiiesslich denen 
der lokhlen Peripherie, 
unfassende Fehlererkennung- und korrektur, 


seibötaendigen Auf- und Abbau physikalischer ünd logischer 
Dateriverbindungen, 
Moeglichkeiten der Datenvorbereitung- und pruefung, 

: bchneliöre Umruestung auf geaenderte Netzwerkfunktionen, 
u; 


Der Steuerrechner ärbeitet nur mit den unmittelbaren Funk- 
tionseinheiten än der vertikalen bzw; horizontalen Ebene des 
E/AsSystems zusammen, Sie werdeh ais E/AsEinheiten des 
Steusrrechhers bezeichnet; E/A=Einheiten koennen sein: 


Subkanaele; 
: &htfeimt küfkestellte GSE, 
> Leitungskonzentratoren; 
; Abonnentenpurikte usw. 
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Fuer das Herstellen einer logischen Datenverbindung werden 
z.Zt. zwei Betriebsweisen genutzt: 


- Aufrufbetrieb und N 

- Anforderungsbetrieb 
Beim Aufrufbetrieb traegt eine E/A-Einheit die Gesamtverant- 
wortung fuer die-Datenuebertragung und legt fest, welche,.E/A- 
Finheit senden darf, Sie wird als Steuerstation bezeichnet, 
Es ist immer diejenige E/A-Einheit, an welcher der VR’ange- 
schlossen ist, Alle E/A-Einheiten, die keine Steuerstation. 
sind, werden als Nebenstation bezeichnet, Eine Station die 
senden kann, heisst Hauptstation. Die Datenverbindung befin- 
det sich im Betriebszustand "Unteroränungsbetrieb", Er wird 
hauptsaechlich bei Zweipunkt- und’ Mehrpunktverbindungen an- 
gewandt. 

Beim Anforderungsbetrieb wird das Herstellen der logischen 
‚Verbindung gleichfalls durch die Steuerstation eingeleitet. 
In diesem- Fall kann sowohl der VR als auch die DEE die 
Steuerstation sein, In.der vorliegenden Version wird diese 
Betriebsweise nicht unterstuetzt, 


3.  Steuerprogrammkomponenten 
3el. Begriffe 


Der Prozess (Task) ist die kleinste in die Ablaufplanung ei- 
nes Steuerprogrammes eingehende Einheit. Er beginnt mit einem 
Anfangszustand und endet mit einem Endzustand, Ein Prozess 
besteht aus. einer oder mehreren Aktionen, die mit einem An- 
fangsereignis beginnen und mit einem Endeereignis enden, 

Die Prozesse, die auf dem Steuerrechner ablaufen, kann man 
unterteilen in: 


- SyStemprozesse und 
- E/A-Prozesse, 


L_ J 
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Systemprozesse werden yon der Komponente "Ablaufsteuerung" 
duroh SyStemtasks verwaltet, E/A-Prozesse von der Komponente 
"E/A=-Steuerung" durch E/A-Tasks, 


3.2. Ablaufsteuerung 


Die Komponente Ablaufsteuerung besteht aus folgenden Tasks: 
h 


Behandlung des Ereignisses Sammelunterbrechung, 
Behandlung des Zeitereignisses, 

Behandlung des Ereignisses Spannungsfehler, 

- Regleprogramm und 

Dynamischer. Stop, 


‘ 
Das Regieprogramm ist fuer die Ablaufsteuerung die wichtigste 
Task, Sie verwaltet die parallel zu bearbeitenden E/A-Prozes- 
se, die sich in einem der Zustaende "Wartend", "Bereit" oder 
Aktiv" befinden, durch die Zustandsaenderungen "Starten", "Zu- 
ordnen" oder "Beenden" (Bild 2), 


ran — lin 


Bilde: :Austandstiiagrtmm von EIA „Prozessen 


ee a u see ln us 


Eine Zustandsaenderung ist als Aktion in einem System-«oder 
E/A-Prozess anzuzeigen. 
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Das Regleprograum wird nach Auswertung eines Ereignisses auf- 
gerufen und startet nach Behandlung aller anstehenden Zu- 
stendsaenderungen die Task "Dynamischer Stop", 

Die Task "Dynamischer Stop" wird dem Prozessor nach der 
Systemanlaufbehandlung zugeordnet, Sie wird verdraengt, 50- 
bald ein Ereignis eintrifft, 

Die Tasks zur ..Behandlung des Ereignisses Sammelunterbrechung 
und des Zeitereignisses arbeiten kooperativ mit den E/A-Tasks 
zusammen, 

Die Task zur Behandlung des Ereignisses Spannungsfehler fuehrt 
zum Halt des prozessors, Nach anschliessendem (Re-) Start 
wird in die Task "Uynamischer Stop" verzweigt. 


3.3% E/A-Steuerung 


Aufgrund von abgrenzbaren Teilfunktionen sind folgende wesent- 
liche E/A-Tasks zu nennen: 


E/A-Initiator, 
Sammelunterbrechungsbehandlung, 
Zeitfehlerbehandlung und 
E/A-Fehlerbehandlung, 


Um eine E/A-Einheit bedienen zu koennen, ist ein ordnungsge- 
maegses Zusammenspiel aller E/A-Tasks erforderlich, ‚Dieser 
Algorithmus wird Treiber genannt, 
Die’ E/A-Task "Sammelunterbrechung" wird von der Systemtask 
zur Behandlung des Ereignisses Sammelunterbrechung aufgerufen, 
nachdem diese die AS ermittelt hat, Wurde eine Sammelunterbre- 
chung durch einen E/A-Fehler verursacht, wird die E/A-Task 
"E/A-Fehlerbehandlung" aktiviert, ansonsten die E/A-Aktion 
des Treibers ausgefuehrt. In der Task ist anzuzeigen, ob der 
E/A-Prozess in den Zustand "Wartend" (Aktion "Beenden") zu 
eberfuehren ist oder im Zustand "Aktiv" (Aktion leer) bleibt, 
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Die E/A-Task "E/A-Initiator" wird von der Systemtask "Ablauf- 
|steuerung" aufgerufen und die E/A-Task "Zeitfehlerbehandlung" 
von der Systemtask zur Behandlung des Zeitereignisses, 

Da ueber den gleichen Typ einer AS unterschiedliche E/A-Ein- 
heiten angeschlossen werden koennen, ist es zweckmaessig, die 
Steuerung der AS von der Steuerung der E/A-Einheiten zu tren- 
nen. Deshalb wird jede AS durch einen physikalischen Treiber 
lund jede E/A-Einheit durch einen logischen Treiber bedient, 
Das Zusammenwirken der einzelnen Hardware- und Softwarekompo+ 
nenten zeigt Bild 3, 


AbLZUFSTEUSTUNG - 


SKeusrrechner 


Abb. 3: Zusammenwirken zwischen Kardiwarö- und Software- 
kemponenten tm Seuertechner 


Se £ 
Logische Treiber wurden bisher realisiert fuer: 


> Multiplexkanal (Ap64, Fernschreiber, IBM 2741 und ES 6012 
fuer die Zusammenarbeit mit BTAM OS/ES), 

- entfernt aufgestellte MPD auf der Basis der APp64-Prozedur 
(Ap64-Emulator), 

- AP64 

- SM 4000/BD. 4000, 

- m 340, 

- PBT 4000 und 

-= CR 600, 


Physikalische Treiber sind vorhanden fuer die AS1, AS2, AS4, 
AS8 und AS9, j 


L_ — 
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Zur Steuerung einer AS gehoeren alle physikalischen Aufgaben 
‚ie Herstellen der E/A-Bereitschaft, Ein- und Ausgabe eines 

Datenbytes, Behandlung von Statusmeldungen, 

In der Steuerung einer E/A-Einheit sind alle logischen Aufga- 
ben zuSammengefasst, wie Starten und Beenden einer E/A-Opera- 
ion, Ausblenden und Einblenden von Vebertragungssteuerzei- 
hen, Kodierung, Pufferung usw, 

Alle zur Steuerung einer AS benoetigten statischen und dyna- 

schen Informationen werden in einem Statussteuerblock (SCB) 

nd die einer E/A-Einheit in einem Einheitensteuerblock (UCB) 
gespeichert, 

Typische statische. Informationen eines SCB sind: 


Maskenbit, 

Adresse der AS, 
Statusregister, 
Time-out-Zaehler usw, 


-zu den statischen Informationen eines UCB gehoeren: 


Adresse des SCB, 
Adresse der Tabelle aller Eintrittspunkte des Treibers 
Adresse der Dat EHUSDORTRABUNEEBTOZENUN (DUEP) usw, 


Die in der DDR realisierten Implementierungen von Steuerpro- 
grammen gehen davon aus, dass nur DEE unterstuetzt werden 
koennen, fuer die eine DUEP vorhanden ist, Die DUEP wird von 
der Zugriffsmethode (ZGM) fuer DFV im VR zusammengestellt und 
die zugeordnete Uebertragungszeichenfolge nach dem Durch- 
schalteprinzip uebertragen, Das 1st bspw. beim MPD1A-Emula- 
tor der Fall. Zur Unterstuetzung von DEE, die nicht zum Mo- 
dellbestand des ESER gehoeren, zum Anschluss mehrerer VR u. 
Aufgaben ist eine Trennung von Nachrichtenkopf und Nachri- 
htentext erforderlich, 
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Dafuer ist sine Nachrichtenvermittlung mit blockweiser Daten- 
uebertragung wesentlich besser geeignet. Das entsprechende 
Verfahren wird "Emulation zur prozedurfreien Datenuebertra- 
gung" bezeichnet und ist Aufgabe des Kanaltreibers, Einzel- 

heiten dazu sind aus /3/ zu entnehmen, 

rundlage fuer eine Emulation ist stets die Nachbildung des 
ollstaendigen Algorithmus zur Informationsuebertragung von 
analprogrammen, Kanalprogramme werden in der Ebene der ZE 
erzeugt. Fuer die GSE ist es belanglos, ob dafuer ueber- 
haupt ein Betriebssystem bzw. eine ZGM benutzt wird. Prak- 
tisch besteht jedoch eine Einschraenkung, da das Achtungs- 
bit vom Statusbyte nicht zum Multiplexkanal uebertragen wer- 
dens 


3.4. Auftragssteuerung 


Die Auftraege, die das Steuerprogramm zu verwalten hat, eind 
E/A=-Auftraege, Ueber die AS4 koennen je Subkanal ein E/A-Auf- 
trag und ueber jede AS2 bzw. ASS je ein E/A-Auftrag parallel 
abgewickelt werden, Somit ist die Anzahl der zu verwaltenden 
E/A=-Auftraege vor der Laufzeit des Steuerprogramms bekannt 

nd kann definiert werden, 

eder E/A-Auftrag wird in einem Tasksteuerblock (TCB) be= 
schrieben und enthaelt Statische und dynamische Informatio- 
nen: 


Verweis zur Steuerstation, 

Verweis zur Nebenstation 

Laenge des E/A-Puffers 

Adresse des E/A-Puffere und 

Verweis zur Liste der Steuerrechner 


eder E/A-Auftrag besteht aus zwei E/A-Operationen, Eine Taten 
ebertragung vom VR zur DEE erfordert eine Eingabeoperation 
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om VR und anschliessend eine Ausgabeoperation zur DEE, 
e Auftragssteuerung hat also nach Beendigung einer E/A-Ope- 
ation fuer die Umkehr der Uebertragungsrichtung zu sorgen. 
[Bei Zweipunktverbindungen ist die Zuordnung Zwischen ankom- 
ender und abgehender Verbindung vor der Laufzeit des Steuer- 
rogramms ‚bekannt. Eine Adressierung entfaellt. Bei Mehrpunkt- 
erbindung ist eine von mehreren abgehenden Verbindungen bei 
ur einer ankommenden Verbindung auszuwaehlen, Es ist ein 
dressverweis zur Auswahl der Verbindung erforderlich, der 
Spw, in der DUEP enthalten sein kann, 

rfolgt der Zugriff vom VR zu einer DEE ueber mehrere Steuer- 
echner muessen die Adressen der Steuerrechner eindeutig im 
etz und die Adressen der am Steuerrechner angeschlossenen 

EE eindeutig vergeben sein, Damit ist es moeglich, dass je- 
er VR im Netz jede DEE eines Steuerrechners adressieren 

enns 

Ein Steuerrechner muss unterscheiden, ob er einen weiteren 
Steuerrechner oder eine DEE adressieren soll. Dazu messen 

hm die Adressen aller Steuerrechner im Netz sowie die Adres- 
sen aller angeschlossenen DEE bekannt Sein, 

ne Netzadresse wird ueber die im Bild 4 dargestellte Listen- 
struktur interpretiert, Wird ein Steuerrechner adressiert, 
enthaelt das Element in der Liste der Steuerrechner einen 
dressverweis zu einem Steuerblock, Die DEE-Adresse wird 

icht weiter ausgewertet, Wird eine DEE adressiert, enthaelt 
as Element in der Liste der Steuerrechner einen Adressver- 
eis zur Liste der DEE. Den Adressverweis enthaelt dann das 
entsprechende Element in der Liste der DEE. 
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Bild 4: Adresseninterpretation im Steuerrechner 


Dieses Adressierungsprinzip wird bspw. in der Systemetzwerk- 
architektur (SNA) /1/ angewendet. Die VR werden als Hosts, 

die Steuerrechner ala Subareas und die DEE als Komponenten 
bezeichnet, 

Die AP64-Prozedur des ESER ist zur Auftragssteuerung gut.ge- 
eignet. sie enthaelt zum Aufbau der logischen, Verbindung u.a, 
wei Adressenbytes; eine Steuereinheit- und eine Komponenten- 
dresse, Der Wertevorrat der Steuereinheitadresse betraegt 

96 Zeichen (Wertebereich '20' bis '7F'); der Komponenten- 
dresse 48 Zeichen (Wertebereich '!30' bis !5F’), 

Damit laesst sich - ohne Aenderung der Geraeteteohnik und Ein- 
riffe in das Betriebssystem einer ESER-EDVAI - ein Rechner- 
netz mit 96 Subareas aufbauen, 
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.5. ‚Kernspeicherverwaltung 


Aufgrund des Prinzips der Nachrichtenvermittlung spielt die 
Bereitstellung von E/A-Puffern zur Zwischenspeicherung: von 
Daten eine besondere Rolle in der Verwaltung des Kern- 
speichers, Beim Aufrufbetrieb ist es ausreichens, je E/A- 
Auftrag einen E/A-Puffer zu definieren, der jeweils der Haupt- 
station zugeordnet wird. 

Fuer Testzwecke ist die Rueckverfolgung von E/A-Operationen 
ein unentbehrliches Hilfsmittel, Alle physikalischen Treiber 
protokollieren jede Datenuebertragung ueber die AS, Eine Pro-= 
tokollierung besteht aus drei Eintraegen: 


- Ereignis (Datenbyte, Statusbyte), 
- Verweis zur ausgefuehrten Aktion, 
- Adresse des Subkanals (nur AS4), 


Das Protokoll wird in einem Umlaufpuffer gespeichert, 


4. Schlussbetrachtung 


Das vorgestellte Steuerprogramm fuer einen Steuerrechner auf 
der Basis des R 4201 hat sich bereits in der Praxis bewaehrt., 
AlS wesentliche Vorteile gegenueber bisherigen Systemunterla- 
genentwicklungen werden gesehen: 


1. Bedienung von DEE, die nicht zum Modellbestand der Abon- 
nznentenpunkte gehoeren, besonders beim Einsatz als MPD, 

2. Aufbau einfacher Rechnernetze ohne Aenderung an der Ge- 
raetetechnik und bei minimaler Aenderung der Systemunter- 
lagen, 

13% Unterstuetzung mehrerer DEE beim Einsatz als Abonnenten- 

punkt ) 

4. Einheitliches und dem Anwender zugaengliches Steuerpro- 
gramm fuer alle Einsatzmoeglichkeiten, 

5. Guenstiger Offline-Test bzw. Fehlersuche, 

N) 


168 


Literaturverzeichnis 


/1/ Kohl,H.: Systems Network Architecture: Rechnernetze, 
IBM-Nachrichten, 26 (1976 )233/234 

/2/ Schnupp,P.: Rechnernetze; Walter de Gruyter, Berlin 

| New York, 1978 

/3/ Schreiter,G.: "Emulator fuer prozedurfreie Datenueber- 
tragung. Rechentechnik Datenverarbeitung 18 (1981 )9 

/4/ Wettstein,H,: Aufbau und Struktur von Betriebssystemen. 
Carl Hanser Verlag, Muenchen Wien, 1978 

/5/ 180/1C97/SC16, Open System Interconnection, 1978 


Verfasser; 


Dipl.-Ing, Guenter Schreiter 

IH Dresden 

Sektion Informationsverarbeitung 
Rechenzentrum 

8019 Dresden 

Hans-Grundig-Str, 25 


169 
Secklowski, Ulrich 


Gedanken zu Gestaltungsaspekten der Bildschirm-Interaktions- 
schnittstelle und ihren programmiertechnologischen Realigsie- 
rungen 


Gestaltungsaspekte der Bildschirm-Interaktionsschnittstelle 
(BS-IAS), die mittels Programme realisiert werden können, sind 
solche, die mit 

- Bildinhalt und Bildform, 

- Bildfolge und 

- Zeitüberlegungen 

zusammenhängen, 


Die folgenden Ausführungen beschränken sich auf alpha-numerische 

Bildschirme. Hinsichtlich der im Dialog zu behandelnden Aufgaben 

ist an solche 

- des Programmierens, 

- der rechnergestützten Unterweisung, 

- an die mittels Auskunfts- und Informationssysteme zu 1ößsenden,. 

- sowie an darüber hinausgehende in der Büroautomation enfallen- 
de. 

gedacht. 


Gestaltungsaspekte der BS-IAS werden häufig subsumiert unter den 

Begriffen Benutzerakzeptanz oder Benutzerfreundlichkeit. Unter- 

Betzende, Teilaspekte werden in der Literatur zahlreich genannt 

und behandelt. Unbefriedigend, und eine umfassende programmier- 

technologische Erschließung erschwerend, sind die unterschied- 

lichsten Herangehensweisen der Autoren und die daraus resultie- 

rende Begriffsvielfalt, entlehnt den verschiedensten Wissensge- 

bieten. So stehen Überlegungen 

- zur Ästhetik und einem zeitgenössischen Stil (Shneiderman 
1979) 

neben. Betrachtungen 

- zu fachspezifischen Dialogsprachen, 

- zur Antwortzeitproblematik, 

oder etwa dem 

- Benutzertemperament (Sacklonski 1981). 


er 
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Ein integraler und damit die verschiedensten Begriffe integrie- 
render Ansatz scheint mit den Aussagen der Kommunikationswissen- 
schaften, insbesondere der linguistischen Kommunikation, gegeben 
zu sein, wobei, da es sich um Arbeitstätigkeiten handelt, Er- 
kenntnisse der Arbeits- und Ingenieurpsychologie einbezogen wer- 
den nüssen. 


Dehning und Maaß haben 1977, ausgehend von zwei Kommunikations- 
modellen, Erwartungen abgeleitet, die ein Mensch an eine zwi- 
schenmenschliche Kommunikation knüpft, und die nach ihrer Mei- 
nung auch in der Mensch-Rechner-Interaktion ihre Relevanz haben. 
Ihre genannten Erwartungen sind folgende: 


Ein Mensch erwartet, 


1. daß sich ein gemeinsamer Kode finden läßt, und daß auch der 
Kode des Partners erweiterbar ist, 

2. beim Partner ein Grundwissen und die Fähigkeit, neue Erfah- 
rungen zu sammeln. 


Er erwartet, daß der Partner 


3. Rücksicht auf die Redekonstellation nimnt, 

4. nach einem partnertaktischen Programm handelt, 

5. von psychischen und "physischen Gegebenheiten abhängig ist, 
6. eine Präzisionsregelung anwendet, 

7. eine zeitliche Regelung anwendet. 


Er erwartet für sich selbst, 


= 


8. daß er das Verhalten des Partners beeinflussen kann, 
9. Möglichkeiten zur Präzisionsregelung, 
„10. Möglichkeiten zur zeitlichen Regelung, 
11. eine Reaktion des Partners bezüglich seines eigenen Verhal- 
tens. 


Die ‘genannten Autoren transformierten diese Erwartungen auf die 
Mensch-Rechner-Interaktion und ordneten ihnen in der Literatur 
genannte BS-IAS-Gestaltungsmerkmale zu, wie sie für sogenannte 
„naive" Benutzer bei Routine-'und bei neuartigen Arbeiten von 
Bedeutung sind. 


Für eine allgemeine programmiertechnologische Erschließung die- 
ses Ansatzes wäre seine tiefergehende Qualifizierung erforder- 
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lich. Dies würde bedeuten: 

i. Bei der Differenzierung der erwartungs-realisierenden NMerk- 
male eine generelle Unterlegung der Hauptaxiome der Kommuni- 
kation (z.B. mittels der Axiome nach Baacke, (1973)). 

2. Eine geordnete und klare Nennung der Merkmale, insbesondere 
in Hinblick auf ihre mögliche Formalisierung, schrittweise 
Verfeinerung und- Abstraktion, und 

3. eine stärkere Einbeziehung der Erkenntnisse der‘ optischen 
Kommunikation und damit der Gestaltgesetze der Psychologie. 


Ein wesentliches Ergebnis solcher Untersuchungen sind Qualitäts- 
merkmale des BS-IAS, 


Qualitätsmerkmale für Programme und Datenverarbeitungsprojekte 
werden seit langem diskutiert. Sie erscheinen jedoch für die 
BS-IAS als noch zu mächtig, noch nicht spezifisch genug, 
als daß sie beispielsweise in der Spezifizierungsphase als aus- 
reichende Richtlinien gelten könnten. 


Ausgehend vom kommunikativen Ansatz erarbeitete Qualitätsmerk- 
male sind hinsichtlich der Aufgabe, des Benutzers und des Rech- 
'nersystems quantitativ untersetzbar (Bild 1). 


BS-IAS-Gestaltungsaspekte 


Qualitätsmerkmale 
1 
' 1] 


quantitative Ausprägung 
f(Rechner- f(Aufgabe) f(Benutzer) 


system) .hierarchisches Bewer- 
tungssystenm 
+. Benutzergruppen 
4‘ 


Bild 12 Qualitative und quantitative Ausprägung von 
BS-IAS-Gestaltungsaspekten 
} 


Einige Bemerkungen zur aufgaben- und, benutzer-abhängigen quanti=- 

tativen Ausprägung: 

1. zur aufgaben-abhängigen, - hier speziell anhand der Präzi- 
sionsregelung. Ein Bestandteil der Präzisionsregelung ist, 
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daß bei fehlerhaften Dialogverlauf die Möglichkeit des Rück- 
sprungs mit erneutem Wiederanlauf geboten wird, 

Als Beispiel für nur eine Rücksprungmöglichkeit, nämlich zum 
Dialoganfang, seien die öffentlichen Dialog-Fahrkartenautona- 
ten mit Bildschirm genennt,„ für zahlreiche Rücksprungmöglich- 
keiten Dialoganwendungen, die der Erstellung von Steuerkerten 
für ein größeres Programm dienen. 

2. zur benutzer-abhängigen, - hier nur zur näheren Erläuterung 
der beiden angeführten Unterpunkte. 
(a) Hierarchisches Bewertungssystem: Gemeint ist das hierar- 

chische Bewertungssystem von Arbeitstätigkeiten der Ar- 

beits- und Ingenieurpsychologie (Hacker 1980). Es stuft 

Arbeitstätigkeiten von ausführbar, über schädigungslos, 

beeinträchtigungslos bis persönlichkeitsfördernd ein. 
(b) Benutzergruppen: Gemeint sind gruppenspezifische Merk- 

malsausprägungen, die sich z.B. aus 

- den Erfahrungen und EDV-Kenntnissen des Benutzers, 

- der Benutzungshäufigkeit der Dialoganwendung 

- und etwa den Alters- und Temperamentscharakteristika 

ergeben. 


Die nüan folgenden Ausführungen hinsichtlich der programmiertech- 
nologischen Realisierung der Gestaltungsaspekte reduzieren sich 
auf die Programmierphasen der Spezifizierung und des Entwurfs. 


In den zurlickliegenden Jahren haben sich die Bemühungen ver- 
stärkt, die Spezifizierungsphase programmiertechnologisch. zu un- 
terstützen. Es sind Methoden, Sprachen und Werkzeuge entwickelt 
worden, die den Spezifizierungsprozeß und die Spezifikation ein- 
schließlich deren Analyse und damit der Überprüfung ihrer inne- 
ren Konsistenz, unterstützen. Zwei Hauptvertreter hierbei sind 
mit den Systemen SADT und ISDOS gegeben, letzteres mit seinem 
Sprachteil PSL und seinem Analyseteil PSA. SADT und ISDOS unter- 
scheiden sich konzeptionell in ihrer Herangehensweise. Während 
ersteres einen integralen Ansatz verfolgt, entsprechend einer 
TOP-DOWN-Strategie, folgt PSL von ISDOS einem singulären Ansatz 
und damit einer BOTTOK-UP-Strategie. Obwohl die sprachlichen 
Mittel beider Systeme teilweise sehr mächtig sind, fehlen jedoch 
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insgesamt Beschreibungsmittel für den Kensch-Rechner-Dialog. 


Die Literatur nennt andere Ansätze für diesen Anwendungsbereich, 
jedoch sind sie nicht so umfassend. 


Bei ihnen können zwei Herangehensweisen unterschieden werden 
- die prozeßorientierte und 
- die zustandsorientierte, 


Beim prozeßorientierten Ansatz werden beim Entwurf des Dialog- 
systens die Teilaktivitäten über parallele, rivalisierende Pro- 
zesse realisiert. Ein solcher Systementwurf gewinnt gegenüber 
einem zustandsorientierten besonders dann an Übersicht, wenn das 
Dialogsystem komplex ist, - viele Dialogzustände hat. Als Bei- 
spiel dafür seien eine weitreichende Kodetoleranz, mit Format- 
freiheit und Freiwortanalyse, und adaptive Systemlösungen ge- 
nannt. 


Weiter verbreitet als der prozeBorientierte Ansatz ist der zu- 
standsorientierte. Ein Hauptgrund wird in seiner klaren Darstel- 
lung des Dialogflusses liegen. 


Der zustandsorientierte Ansatz geht auf die Theorie endlicher 
Automaten zurück und beschreibt für jeden Dialogzustand die mög- 
lichen Eingaben und die daraus resultierenden Folgezustände. Von 
den zuswiner Darstellung entwickelten Hilfsmitteln soll kurz 
auf die Petrinetze, die petrinetzähnlichen Instanzennetze, In- 
teraktionsdiagramme und Dielogablauftabellen eingegangen werden. 


1. Zu Petrinetzen und petrinetzähnlichen Instanzennetzen: 
Das Beispiel in Bild 2 zeigt einen Ausschnitt eines Dialogsy- 
stens zur Programmentwicklung. Je nachdem, ob im Petrinetz 
die Bedingung „Compilation" oder „Keine Compilation" markiert 
ist, findet das Ereignis E1 saer E2 statt. 


.„ Petrinetze eignen sich für den Nachweis der Sicherheit und 
Konfliktfreiheit der’ Programme von Dialogsystemen. Ihr Be- 
schreibungsniveau ist jedoch sehr niedrig, die Übersichtlich- 
keit geht schnell verloren. Deshalb wurden Petrinetze erwei- 
tert und dabei neben der Darstellung des Steuerflusses beson- 
deres Gewicht auf die Wiedergabe des Datenflusses_gelegt 
(Bild 3). 
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Die hiermit gewonnene Transparenz geht allerdings auf Kosten 
von Einzelinformationen. Diese können dann beispielsweise mit- 
tels Pseudocode hinzugefügt werden. 


Bild 2: Beispiel für. ein Petrinetz (Schmid 1973) 


| 


) 
1} 
(BCOMP.BKCOMP ı 


M: if Bi = marked 

then if BCOMP,BKCOMP = BCOMP 
then mark (B3) 
else mark (B2) 
e BCOMP,BKCOMP:= BCOMP 

i 
else goto M 
fi 


Bild 3: Beispiel für ein petrinetzähnliches Instanzennetz 
(Schmid 1973). Dabei verwendate Kanalklassen; 
(1) Kanal mit der gleichen Funktion wie Bedingungen 
in Petrinetzen 


Kanal: ®:: ; Kantes ———— 
(2) Kanal durch Zusammenfassen von => 2 Bedingungen 


Kanal: ( B1,B2 ) ;s Kante: — — — = 


(3) Kanal nit komplexen Informationen (z.B. Programm- 


baustein) 
Kanal: ; Kante: — — —- 


De 
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Zu Interaktionsdiagrammen: 

Interaktionsdiagramnme sind eine spezielle Art der Zustands- 
diagramme, die sich besonders für die Spezifizierung und den 
Entwurf von Dialogsystemen nach dem Verfahren der schrittwei- 
sen Verfeinerung eignen. Ihre Syntax und. Semantik sollen an- 
hand eines Beispiels angedeutet werden. Es entstammt dem me- 
dizinischen Bereich und ist Untersuchungen von Budde u.a. 


-(1980) entnommen (Bild 4). 


Zur Erläuterung von Bild -4: 

= Dreiecke bedeuten Anfangs-. bzw, Endzustand 

= Kreise entsprechen Interaktionspunkten; mit eingefügten 
"I" = Terminal 

- einfach gerahmte Rechtecke entsprechen einfachen Zuständen, 
sie beinhalten Verarbeitungsabläufe ohne weitere Interak- 
tionen mit dem Dialogpartner 

- doppelt gerahmte Rechtecke entsprechen "komplexen Zustän-. 
den", sie werden durch zusätzliche Interaktionsdiagramme- 
verfeinert und in ihnen können weitere Interaktionen mit 
dem Dialogpartner vorkommen 

- Striche mit darangeschriebenen Bedingungen dienen der Dar- 
stellung von Zustandaübergängen. 

Der untere Ablauf des Beispieis gibt eine erste Verföinerung 

des komplexen Zustandes "Rezeptdruck" wider, 

Ein solcher Dialogablauf in graphischer Form ist auch in Ta- 

bellenform möglich. Diese wurde bei uns vom VEB Carl Zeiss 

Jena publiziert (Rothardt 1979). 


Abschließend zwei kritische Bemerkungen zu allen genannten Dar- 
stellungsformen: 


1° 


2. 


Allen fehlen Zeitangaben, Auf Grund der erkannten hohen Rele- 
vanz der Antwort=-Zeit-Problematik und der einfachen Einfü- 
gungsmöglichkeit sollten Antwortzeitforderungen mit aufgenm- 
men werden. 

Im Beispiel von Bild 4 sind die maximalen Antwortzeiten in Se- 
kunden in eckigen Klammern hinzugesetzt worden. 


Alle lassen das "GOTO" und damit einen nichthierarchischen 
Steuerfluß zu. Dies ist sehr bedenklich, da Erkenntnisse der 
Arbeits- und -Ingenieurpsychologie hinsichtlich der geistigen 


v 


Rezertdruck er | 


Patienten- 
Erfassung 


| Ende: Prozedur 


Med.-Anfangsb. 


Med.- Ausinhl 
aufbereiter 


| Rezept zeile 
aufbereiten 


Bild 4: Beispiel für ein Interaktionscliagramm mit 
Verfeinerung des“„komplexen Zustandes" Rezeptdruck 7 
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Repräsentation von Arbeitstätigkeiten, also auch bei der Ar- 
beit mit einem Dialogsystem, besagen, daß hierbei grundsätz- 
lich von einer 'hierarchischen ‘Struktur und Ablaufsteuerung 
auszugehen sel (Hacker 1980; Bild 5). ) 


® Han dlungs vorbereitung 


| 
Handlungs vollzug 


Richten 
(Metiv/Ziel] | 
| Vorsatz ee 
Orientierung | ı 
Kae ep hierarch. 
(für Zieldiff., Ergebnis- 
Al | modell j requlierende 
rüfung) (Ziele) als (hierarchisch 
5 tat nisierte 
| a nenn Funkkions- 
Entwerfen u einheiten 
4 | | (Aktions- (Tore) 
Entscheiden | prögr-) 
| Kontrollieren 


Bild 5:Grob schematisierter Überblick über Glieder und Zusammen- 
hange der psychischen Regulation von Arbeitstatigkeiten 

Innerhalb des Schemas von Bild 5 ist der rechte Teil von Interes- 
se, also der den Handlungsvollzug charaktsrisierende. Die dorti- 
gen Invarianten entsprechen relativ beständigen tätigkeitsregu- 
lierenden psychischen Gebilden und sind Teile des inneren Mo- 
dells oder, wie man auch sagt, des operativen Abbildsystens. Zu 
ihrer Struktur sagt Hacker: „Vornahmen und ihrer Realisierung 
dienende Pläne stehen in einem durch die Logik der Aufgabe be- 
dingten Unterordnungsverhältnis, sie sind hierarchisch 'ver- 
schachtelt'!. Der Hierarchie der Zielsetzung entspricht eine Hier- 
archie der Pläne, allgemeiner der Aktionsprogranne", 
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Und an anderer Stelle schreibt Hacker: „Das operative Abbildsy- 
stem reguliert Arbeitstätigkeiten vermittels funktioneller Ein- 
heiten von in die Zukunft ausgreifenden,. hierarchisch gestaffel- 
ten Vornahmen und zu deren Verwirklichung dienenden, entspre- 
chend organisierten Handlungs- oder Aktionsprogrammen, die of- 
fenbar gleichfalls hierarchisch organisierte Rückkopplungspro- 
zesse (Kontrollprozesse mittels TOTE-Einheiten) einschließen", 
Dies bedeutet: Äquivalenz in Struktur und Steuerfluß zwischen‘ 
'1. der im Dialog zu lösenden Aufgabe und 

2. ihrer geistigen Repräsentation und 

3. des entworfenen und implementierten Dialogsystens 

läßt nur eine durchgängig hierarchische Struktur und einen durch- 
eängig hierarchischen Steuerfluß zu. 
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Vergleich rechnerunterstützter Spezifikationsverfahren 


1. Einführung 
In den letzten Jahren entstand ein wachsendes Interesse an 


allen Phasen der Programm-Entwicklung, nachdem-bisher die 
späteren Phasen, z.B. die Codierung (und damit die Progran- 
miersprachen) ganz im Mittelpunkt gestanden hatten. Dabei 
wurde offensichtlich,. daß eine Verbesserung der Qualität von 
Softwareprodukten sich nur dann erreichen läßt, wenn es ge- 
lingt, die Phasen, die vor der Programmierung liegen, zu 
systematisieren und zu rationalisieren, d.h. Hilfsmittel zur 
Verfügung zu stellen, die es ermöglichen 
- die Anforderungen an die Problemlösung. genau und 
in einer für die weitere Programmentwicklung ge- 
eigneten:Form zu beschreiben, 
- Mängel der Anforderungen zu erkennen, 
- den Spezifikations- und Entwurfsvorgang ausreichend 
zu dokumentieren. 
Ausgehend von diesen Überlegungen wurden Spezifikationssysteme 
entwickelt, die es versuchen, einen möglichst großen Teil des 
Programm-Lebenslaufs zu decken. Folgende Definition kann für 
ein Spezifikationssystem formuliert werden: 
Ein Spezifikationssystem ist ein instrumentiertes und organi- 
siertes Software-Entwlcklungs-Laboratorium, in dem viele 
Personen arbeiten, um gemeinsam in einem vollständig organi- 
slerten Arbeitsprozeß Software zu entwerfen, zu konstruieren, 
zu prüfen, zu Ändern und zu warten /1/. 


2., Vergleich der Spezifikationssysteme 


Die Spezifikationssysteme können nach folgenden Kriterien 
verglichen werden: 

- Ideen 

= Ansätze. 

- Art und Grad der Formalisierung 
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- Anwendungsbereich und dazugehörige Motivation und 
Ziele 


2.1. Ideen 
Die Spezifikationssysteme beruhen wesentlich.auf folgenden 


Ideen: 

- spezielle Methoden der Softwareentwicklung 
Structured Design AIDES 
Jackson-WNethode DSL 

- Sprachkonzepte 
CDL2 CDL2-Laboratorium 
Path-expressions COSY 
Pseudocode TESO 

- Hanagement-Verfahren 
Projektlenkung. SDEM/SDSS 

- besondere Ansätze 
besonderer Systembegriff DELTA/BETA 


(Computer-(Software-) System = 
Teilsystem in einem umfassenden 
soziotechnischen System) 


2.2. Ansätze 
Bei den Ansätzen für Spezifikationssysteme unterscheiden wir; 

- homogener,'heterogener Ansatz 

- integraler, singulärer Ansatz 

„- aktionsorientierter, datenorientierter Ansatz 

Ein homogener Ansatz ist ein solcher, der im wesentlichen um 
eine Techrik gruppiert ist und der (in den meisten Fällen) 
"auch historisch aus dieser Technik hervorgegangen ist. 
Ein heterogener Ansatz entsteht durch Integration verschiedener 
gleichberechtigter Techniken, die nacheinander oder auch wahl- 
weise für die verschiedenen Entwicklungsaufgaben eingesetzt 


werden können. 
Bild 1 zeigt einen Vergleich zwischen ‚homogenem und hetero- 
genem Ansatz. 
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homogener Ansatz | heterogener Ansatz 


Deckung des gesamten \ 

Software-life-cycle schwer erfüllber | gut erfüllbar 
Flexibilität des SI | ST 2 
Einsatzes En wird erschwert wird erleichtert 


Übergänge zwischen ver- 


schiedenen Entwicklungs- leicht a schwer 
phasen einfach | \ kompliziert 


Validation _ wird erleichtert 
Beispiele CDL2-Lab. ‚TESO EPOS, HM 


Bild 1 


| 


Bei dem integralen Ansatz wird jeweils eine Ebene als Ganzes 
betrachtet und beschrieben. 

Bei dem singulären Ansatz betrachtet man nacheinander jeweils 
einen speziellen Aspekt und beschreibt alles, was mit diesem 
Aspekt zu tun .hat. 

Bild 2 zeigt einen Vergleich zwischen integralem und singulärem 


Ansatz./2/ 
singülärer Ansatz 


N 
[kenpakte menchrettung ___ Jaufmenäsge beschretbung 
|übersichtliche Beschreibung ohne automatische Dokumentations- 


werkzeuge unübersichtlich 
Zusammenhänge sind sichtbar 


fördert ganzheit e 
Problemsicht 


Zusammenhänge nur. durch automatl- 
sche Analysen sichtbar. 


-Ordert vereinzelte 
Problemsicht 


En 


Bild 2 
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Bei den aktionsorientierten Ansatz stehen die ade im 
Kittelpunkt. Die von diesen Aktionen verarbeiteten Daten werden 
den Aktionen zugeordnet (z.B. HIPO). 

Bei dem datenorientierten Ansatz stehen die Daten im liittel- 
punkt. Zugriffsoperationen werden zugeordnet (z.B, Jackson- 
Methode). 


2.3. Art und. Grad der Formalisierung 
Nach Art und Grad der Formalisierung lassen sich Spezifikations- 


systeme stark vereinfacht in natürlichsprachliche, programmier- 
sprachliche und ‚mathematische einteilen. 
Im Bild 3 werden die drei Ansätze verglichen, 


natürlich- programler- mathematisch 
ERreeH oh (sprachlich - 
Syntex 
ae nein 
Semantik = 
e formalisiert nein 
a RSL, Spezi, 
| axiomatische 
Spezifikationen 


Beispiele . [PSI-Projekt- 
Su technik“ 


Bild 3 


2.4. Anwendungsbereich und dazugehörige Motivation und Ziele 
Nan kann drei Anwendungsbereiche unterscheiden; 

- Forschungsbereich 
industrieller Bereich 
öffentlicher Bereich 
Motivation und Ziele des Forschungsbereiches sind es, Mittel 
zu schaffen, mit dem kietioden, Modelle, Verfahren, Techniken 
oder Werkzeuge für Software-Produktionsaufgaben laborartig 
entwickelt und erprobt werden können. 
Im Forschungsbereich unterscheidet man wissenschaftliche 
(z.B. Entwicklung von lethoden zur Systemkonstruktion) und 
technische Ziele (z.B. Qualitätsverbesserung von Software). 
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Im Forschungsbereich werden homögene Spezifikationssysteme 
bevorzugt. Beispiele dafür sind CO3Y, DREAM, CDL2-Laboratorium. 
Motivation und Ziele des industriellen Bereichs sind die Hand- 
habung großer Produktionsprojekte. Es werden heterogene Spezi- 
fikationssysteme bevorzugt, die stark durch die }Iranche be- 
einflußt werden, in der das jeweilige System eingesetzt wird. 
Es gibt im inäustriellen Bereich technische Ziele wie: 

- Qualitätsverbesserung von Software, 

- Berücksichtigung der Anwenderaspekte, i 

- Unterstützung von Nethoden der Software-Entwicklung, 
und es gibt auch wirtschaftliche Ziele wie: 

- Kostenreduzierung, 

- Produktionssteigerung, 

- Produktionskontrolle. 
Beispiele dafür sind CADES, AIDES. 
Kotivation und Ziele des öffentlichen Bereichs sind Standar- 
disierung und Normung von Frodukten und Produktionsverfahren, 
um bestimmte Qualitätsmerkmale zu sichern. 


3. Werkzeuge 


Wesentliche technische Komponenten der Werkzeuge sind: 

- Sprachen für die Anforderungsdefinition und 
Systemspezifikation 

- Instrumente und Verfahren zur Kontrolle und 
Verbesserung der Software-Qualität 

- Werkzeuge zur graphischen Darstellung von Software 

- Informationssysteme für technische "itarbeiter 
und für. das Management 5 

- Werkzeuge für Produktionsplanung, Plankontrolle 
und Kontrolle des Froduktionsprozesses 


4. Einordnung von Verfahren 
Bild 4 /1/ und 5 /1/ geben eine Übersichtseinordnung von Ver- 


fahren. Bei Bild 4 sind die Verfahren nach ihrer grundsätzli- 
chen Yethode eingeteilt, dagegen gibt Bild 5. eine Übersicht 
über existierende Software-Entwurfssysteme, die durchaus mehre- 
re grundsätzliche Methoden unterstützen können (heterogene 
'Systene). 
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RPHRUaBOF AFP Hrn od > 


low 
level 
niedrig 


Ideen Prosa Fseudo-Code Code 


informal sprachliche Freiheit formal 


Eild 4 
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Spezifikationssystem- Unterstützung der Bemerkungen, spez. 
bezeichnung EROSNEB LO rl -FüJZiele, Anwendunge 


CDL2 Compiler Descrip- CDL2_ Übersetzerbau, 
tion Language System-Programn. 
COSY Concurent cosy Betriebssysten-. 
Systems ntwicklung 


Ip Computer- -aided, 


Intuition-guided .Progr. L. Prograinmentwickl. 


PDS Program Develop- a Programmentwickl. 
ment: Systen : durch Transforn. 
HDM Hiererchical Veve- PARNAS- 
lopment kethodology _ Spezifikationen 
SDS Software Develop-” [RSL PDS große NMilitär- 
ment system projekte 
CADES Computer Aided S L £ ee Betriebssystem- 
Design Eval. System a entwicklung 
AIDES Automated Inter- ScG (SD) 
ective Design and Da 
al. System 
Unterstützung 

ee teilweise bzw. geplante Unterstützung 
Phasen: 
AN: Analyse SS: Subsystem-Integration 
DF: Definition SI: System-Integration 
SE: Systementwurf IN: Installation 
KE: Komponentenentwurf BW: Betrieb & :Wartung 
kI: NKodul-Implementierung 
’Projektfühgung: \ 


PL: Projektplanung 

SZ: Aufwandsschätzung/-planung 

05: Qualitätssicherung 

BS: Bewertung, Statistik \ 
Bild 5 
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Auf dem Gebiet der Entwurfssysteme läuft gegenwärtig eine außer- 
ordentlich intensive Entwicklung-ab, so daß eine Übersicht 
keinen Anspruch auf Vollständigkeit erheben kann. khnliches 

gilt auch für Fragen der Sinordnung dieser Systeme. 
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Pfeiffer, Peter 


MoauTkopplung durch interne Datenkommunikation 


1. Datenstromnetzwerke 


Der Begriff „Datenstromnetzwerk" (DSN) ist durch Weiterentwick-. 
lung der Grundzüge der datenorientierten Entwurfsverfahren ent- 
standen. ! 


Grundgedanke der datenorientierten Entwurfsverfahren ist die 
Widerspiegelung der Strukturen von Ein- und Ausgabedaten im 10» 
gischen Skelett des Programms, das diese Daten verarbeitet bzw. 
erzeugt. 


Zur Lösung von gewissen Strukturkonflikten (Begrenzungskonflik- 
ten), die zwischen den verschiedenen Datenstrukturen auftreten 
können, wird vorgeschlagen, durch vor=- bzw. nachgelagerte Routi- 
nen (Unterprogramme, Coroutinen) Datenstrukturtransformationen 
vornehmen zu lassen. Weitere Komplikationen ‚bei der automati- 
schen Erzeugung des Programmskeletts entstehen durch die paralle- 
le Verarbeitung mehrerer Eingabedateien sowie durch die Reali- 
sierung von Backtrackingalgorithmen. Datenstromnetzwerke entste- 
hen dadurch, daß man 


« die Lösung von Begrenzungskonflikten durch Hintereinanderschal- 
ten. von Moduln, die einen Strom von Eingangsdaten in einen 
Strom: von Ausgangsdaten umformen, anstrebt (Arbeitsmoduln); 


\ 

« Prozesse, die mehrere Eingabedatenströme zusammenfassen, in 
gesonderte Moduln verlegt, die für die nachfolgende Verarbei- 
tuhg nur einen Ausgabestrom. erzeugen (Mischmoduln); 


. Frozesse, die aus einem Eingabedatenstrom verschiedene Ausga- 
bedatenströne erzeugen, ebenfalls in speziellen Moduln kon- 
zentriert (Filtermoduln); 


. Backtrackingprozesse durch spezielle Moduln realisiert, die 
aus einem Eingabedatenstrom einen "guten" Ausgabedatenstrom 
herausfiltern und an einem zweiten Ausgang einen "schlechten" 
Datenstrom bereitstellen; 
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» die Bereitstellung von Eingabedatenströmen speziellen Moduln 
überl&äßt, die die für die Kommunikation erforderlichen Daten- 
strukturen emittieren (Quellen); 


. die Ausgabedatenströme in Moduln münden läßt, die die physi- 
sche Ausgabe realisieren (Senken), 


Eile aus den beschriebenen Moduln zusammengesetzte Modulstruktur 
wird hauptsächlich durch die durch die Moduln "fließenden" Da- 
tenströme beschrieben = die Modulfunktionen sind bei dieser Be- 
ERROHEUDBENELBE von ‚nachgeoräneter Bedeutung - aus diesem Grun- 


werk gewählt. 


Zwischen den Moduln (Gliedern) eines DSN findet eine Übergabe 
von Datenstrukturen statt - und zwar ausschließlich in einer 
Richtung. Diese, die verschiedenen Gliedern eines 'DSN koppeln- 
zeichnet. Die Daten, die ein DSN- "durchströnen", 'n£ließen" aus 
den Quellen. über Misch-, Filter- und Arbeitsglieder in die 
Senken. 


Sind‘ DSN rückführungsfrei, d+h., die Ausgangsdatenstrukturen 
werden nicht an ein Glied. als Eingangsstrukturen herangeführt, 
das die Voraussetzungen für das Erzeugen der Ausgengsstrukturen 
schafft, so handelt es sich um lebendige Netze - eine deadlock- 
Situation kann nicht eintreten. Derartige DSN sollen als von 
erster, Ordnung bezeichnet werden. 


DSN höherer Ordnung = sie enthalten Rückführungen und sind u.Ü, 
über Warteschlangen gekoppelt - müssen nicht notwendig lebendig 
sein. Derartige DSN sollten auf "deadlock-Freiheit" untersucht 
werden. Im folgenden werden derartige Strukturen und die mit 
ihnen zusammenhängenden Probleme nicht näher untersucht. 


Datenstromnetzwerke werden vorteilhaft mit den Mitteln der 
Graphentheorie modelliert. Die Kanten widerspiegeln Datenströme 
(interne Datenkonmunikation), die Knoten entsprechen den Glie- 
dern des DSN. Ein DSN erster Ordnung wird demnach durch einen 
gerichteten, schlichten, kreisfreien, endlichen Graphen wieder- 
gegeben (s. Bild 1). 


Bild 1: Wiedergabe eines DSN durch einen Graphen 


Graphentheoretische Mittel wie 


. Dekomposition 

«. Kondensation 
Vereinigung 

. Durchschnittsbildung 


und graphentheoretische Hilfsmittel wie 


. Eingangsinzidenzmatrix 
« Ausgangsinzidenzmatrix 
. Knotenadjazenzmatrix 


unterstützen den Entwurfs-, Implementierungs- und Testungsprozeß 
von DSN. 


2. Klassifikation’ von Netzwerksknoten 


Ordnet man den Knoten Ein- und Ausgangsvalenzen zu, so lassen 
sich folgende Knotentypen erkennen: 


v* =0, V” = 1: Quellglieder 


vr =.1, V” = 0: Senkenglieder 

vr = 2, Ve 1: Glieder zur Datenstromzusammenführung 
vr = 1, V” = 2: Glieder zur Datenstromaufspaltung 

vr =1, V” = 1: Arbeitsglieder. 


In Bild 2 sind die aufgeführten Knotenklassen dargestellt - zu- 
sätzlich wurden einige Knotenklassen näher spezifiziert. Jeden 
der näher spezifizierten Knotenklassen (z.B. Mischglieder - MERGE) 
sind Klassen von Algorithmen zugeoränet, von denen ein Algorithr 
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mus ausgewählt werden muß, um.einen realen Knoten implementieren 
zu können. 


V'=0 vr=1 
v1 (0) V=0 ( ) 


SEND (Senden), RECEIVE (Empfangen) 
v’=2 v'n1 

Val Va2 

MERGE (Mischen) FILTER (Filtern) 
CONCATE (Verketten) DUPL. (Duplizieren) 
SEQUENCE (Reihen) DECONC (Entketten) 


v'=1 O 
VA 

PROD (ürzeugen) 
CNTRL (Steuern) 


Bild 2: Übersicht über die Knotenklassen im graphentheoreti- 
schen Modell eines DSN j 


Neben den dargestellten Gliedern sind gegebenenfalls weitere zu 
entwerfen - beispielsweise spezielle Mischalgorithnen bei denen 
die Daten an den Eingabeschnittstellen Über einen zeitgesteuer- 
ten Abtastalgorithnus sequentialisiert werden u.a. 


Die Knotenklassen 
Glieder zur Datenstromzusammenführung 
und 
Glieder zur Datenstromaufspaltung 
(Standardglieder) werden mittels Makroinstruktionen realisiert, 
wobei die Algorithmenauswahl durch Makroparameter gesteuert wird: 
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Die Makroexpansionen führen zu hocheffektiven Assemblerprogran- 
men, die über die Schnittstelle "Datenstruktur" mit jedem in 
einer beliebigen Programmiersprache implementierten Nachbarmo- 
dul zusammenarbeiten können, sofern dieser die genannte Schnitt- 
stelle realisiert. | 


Die eigentliche Leistung eines DSN wird in den Arbeitsgliedern 
vom Typ PROD realisiert. Das logische Skelett derartiger Ar- 
beitsglieder wird weitgehend automatisch aus den miteinander 
korrespondierenden Datenstrukturen generiert. Das Generierungs- 
‚ergebnis besteht aus einer Folge von Anweisungen in einer Zwi- 
schensprache und wird durch den Entwerfer präzisiert. Die Zwi- 
schensprache wird dann durch einen Prozessor in eine beliebige 
Zielsprache umgewandelt. Das Skelett schließlich wird durch die 
erforderlichen Aktionen (lineare Anweisungsfolgen) in der Ziel- 
sprache, in der das betreffende Arbeitsglied realisiert werden 
soll, komplettiert « Das das Arbeitsglied darstellende Programm 
wird anschließend mit.einem Übersetzerprogramm für die Zielspra- 
che übersetzt und gegebenenfalls mit der Gesamt- oder einer 


Teilstruktur zu einem Lademodul verbunden. i 


Für Quellglieder, Senkenglieder und Arbeitsglieder vom Typ 
CNIRL sind vorerst keine Entwurfs- und Implementierungshilfs- 
mittel vorgesehen. 

Y 


In graphentheoretischen Modell von DSN symbolisieren die Kanten 
Datenstrukturen, die der Modulkommunikation dienen (kommunika- 
tive Datenstrukturen). 


Für die interne Datenkommunikation wird generell das variable 
Datenformat benutzt. Die Daten werden mittels geeigneter Koppel- 
mechanismen (s. 4.) an den Modulschnittstellen übergeben. Da 
aus den Datenstrukturen in entscheidenden Netzwerksknoten die 
Logik des zugeordneten Moduls hergeleitet wird, muß es Möglich- 
keiten einer möglichst maschinenverarbeitbaren Beschreibung der 
Kanten und Knoten eines DSN geben. 


Übersicht 1 gibt den ersten Entwurf einer deskriptiven Sprache 
für derartige Zwecke wieder. 
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programn::= datendefinitionsteill .- relationenteil. 

\ + 
datendefinitionsteil::= [datendefinitionsenweisung ] 
datendefinitionsanweisung::= 'DEF'.name.": .datendefinition 


‚datendefinition:s= terminaldefinition | sequenz | alternative} 
iteration | record | group | file 


terminaldefinition::= (FIXED ] FIXED SHORT | FLOAT SHORT | 
i 051 
FLOAT | FLOAT LONG | CHAR. [ (ezehl .)] | 


; 0:1 
HEX. f (;zehl.) | | DECIKAL. [(.zabl.) } E | 
BOOLEAN |REFERENCE). . 
re et a 
sequenz::= ( .name.| „ „name } ee 


+ 
alternative::= "(" name. [" 3" .nane } ee 


rt .. ve 0:1, u. 
iterationss= ( «name. & „zahl. [ : zahl | .)e 

record::= "RECORD OP'.(sequenz|alternativejiteration) 

group::= "GROUP OF' .(sequenz | alternative | iteration) 

file::= "FILE OF'.(iteration|'C' .name.' ‚um).'|'C'.name.' ‚u+).') 
namezz= oo. 

zahl::= ... \ 


. + 
relationenteil::= [relationsdefinition } 


relationsdefinition::= "REL' „name. : .relationsspezifikation 


1.23 
relationsspezifikation::=relationstyp. ( .„[relationsoperand} A 


relationstyps:= PROD|CHTRL|DUPL |FILTER.£iltertyp|CONCATE | 
SEQUENCE |DECONC| MERGE.mergetyp|SEND |RECEIVE 

relationsoperand::= 

filtertyp::= ... 

mergetypi:= ... 


Übersicht 1: Erster skizzenhafter Entwurf einer deskriptiven 
Sprache zur Beschreibung von DSN 


193 


Die mittels einer derartigen Sprache erfolgende Spezifikation 
der Datenströme im DSN ist im allgemeinen ein iterativer Pro- 
zeß, der in eine dialogfähige Umgebung eingebettet werden muß. 
Die Generierung der Standardglieder und die Parserbereitstellung 
für die Arbeitsglieder erfolgt ebenfalls durch die Nutzung ent- 
sprechender Sprachkomponeten. 


Das graphenthegretische Modell des DSN entsteht dabei sukzessive 
und kann das entscheidende Element der entwurfsbegleitenden Do- 
kumentation bilden. 


Die Schnittstelle "Datenstruktur" erlaubt es, die zu koppelnden 
Module in beliebigen Sprachen zu implementieren, wenn diese 
Sprachen Mittel zur Realisation der Koppelmechanismen. enthalten 
oder nützen können. 


Für die Kopplung von Moduln eines DSN werden folgende Koppel- 
mechanismen eingesetzt: 


- explizite Sequentialisierung (explicite sequencing) liber 
..ein symmetrisches Coroutinenkonzept, 
. ein hierarchisches Coroutinenkonzept; 
- implizite Sequentialisierung (implicite sequencing) über. 
. ein MAILBOX-Konzept 
[-CONS;MARL,KMQ,GRU]. 


Die implementierten oder in Implementierung befindlichen Konzepte 
sind den speziellen Erfordernissen der Ausbildung einer Schnitt- 
stelle zur internen Datenkommunikation angepaßt. An den Schnitt- 
stellen werden Datensätze der internen Kommunikation in Puffern 
bzw. Warteschlangen übergeben. 


Die nachfolgenden Beispiele zur Illustration der Koppelkonzepte 
sind in einer Assemblernotation niedergeschrieben die einer rea- 
len Implementation (SKODA - [pre)) entspricht. Bild 3 gibt die 
Kopplung über symmetrische Coroutinen wieder - solche Coroutinen 
sind zur Realisierung von Rückführungen vorgesehen. Die dort ver- 
wendete Makroinstruktion #CCALL realisiert den Aufruf einer 
syrmetrischen Coroutine, .die im PROGRAM-Makro als Coroutine aus- 
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gewiesen ist und dementsprechend generiert wird. 


PROGRAM CO1,0PTION =-FROGRAM CO2,0PTION w-FROGRAM C03,OPTION 
N 


=COROUT =COROUT =COROUT 
LOGIC .LOGIC LOGIC 


#CCALL CO1,(...)- 
ENDLÖGIC ENDLOGIC 
END | END 


ENDLOGIC 
END 


Bild: 3: Modulkopplung über symmetrische Coroutinen 


Bild 4 zeigt einen Anwendungsfall für das hierarchische Corou- 
tinenkonzept. Hierin wird mit DCBC ein Steuerblock im Master- 
modell generiert, über den die Modulkopplung erfolgt - durch 
#0PENC wird der Steuerblock eröffnet und durch #CLOSEC geschlos- 
sen. Die Datenkommunikation wird mittels der Makroinstruktionen 
#GETC bzw. #PUTC durchgeführt. Im nachgeordneten Modul, der 
über keinen Steuerblock verfügt, wird im befehlenden Makro der 
Parameter SLAVE kodiert. 
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Mi M2 


PROGRAM M1 


DCBC PORT,PRODUCEL 


$0PENC (PORT,M2) 
. ENDLOGIC 
END 


#PUT PORT, ... 


#PUIC PORT, ... 


#CLOSEC PORT 


ENDLOGIC 
END 


Bild 4: Modulkopplung über das hierarchische Coroutinen- 
konzept 


Bild 5 stellt die Modulkopplung über "implicite sequencing" 
dar. Den zu koppelnden Moduln wird ein Startmodul übergeord- 
“net, der mittels der Makroinstruktionen STARTB, BOX und STARTE 
problemlos generiert werden kann. Aufgabe dieses Startmoduls 
‚ist der Start der dann asynchron arbeitenden zu koppelnden Mp- 

duln.Mi1 und M2, 


PROGRAM M1 
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STARTB X 
BOX PROD=M1,CONS=M2 ,EXPORT=PORT1 ,IMPORT=PORT2 
STARTE 


PROGRAM M2 


“ 
“ 
®. 


DCBM PORT1,PROD,LRECL=84,VOL=20 DCBM PORT2,CONS,LRECL=84 ,VOL=20 


#0PENM PORT 


#PUTM PORT1,... 


#CLOSEM PORT 


N 
HOPENM PORT2 


#GETM PORT2,... 


HCLOSE PORT2 


ENDLOGIC 
END 


Bild 53° Modulkopplung durch "implicite sequencing" 


ENDLOGIC 
END 
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Analog zum hierarchischen Coroutinenkonzept (vgl. Bild 3) werden 
durch den DGBM ein Steuerblock in jedem der zu koppelnden Modu- 
le generiert, der durch #0PENM eröffnet und durch HCLOSEN abge- 
schlossen wird. x 


Durch #GETM werden aus der durch die OPENM-Routine bereitge- 
stellten Box Datensätze der internen Kommunikation entnomnen, 
durch #PUTM werden derartige Sätze in die Box überstellt. 


Im Rahmen der Realisierung des Nakrosystens SKÖDA [PFE]sind bis- 
her implementiert j 


- die aufgeführten Coroutinenkonzepte, 
- die Zwischensprache zur Strukturierung der Logiks 


Im Stadium der Implementierung sind 


‘= Makroanweisungen zur Generierung von .Standardgliedern, 
- Skelettgenerator. 


Ferner wird an der Implementierung 0.8. Komponenten für andere’ 
Zielsprachen (z.B. FORTRAN) gearbeitet. 


Die Realisierung des gesamten Entwurfskonzepts ist bis 1985 ge- 
plent. 
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Richter, Eckhart 


Tauscher, Wolfgang 


Zur- Verwendung von Datenabstraktionen Tunter- besonderer Beachtung 


1: Vorbenerkungen 


In letzter Zeit wurde die Bedeutung der Abstraktion bein Entwurf 
von Software Adutlich erkannt /3/« Unter Abstraktion versteht man 
eine allgemeine ingenieurtechnische Methode, um bei der 
Betrachtung komplexer Systeme und Wirkmechanismen die wesentlichen 
von den unwesentlichen Seiten zu trennen. 

Erfahrungsgemäß besteht eines der größten Brönlene bein Entwurf 
eines Softwaresystens darin, das konblexe Gesantsysten in 
hinreichend einfache und verifizierbare Teilsystene und 
Einzelprinzipien zu’zerlegen. Alle Schritte bei einer solchen 
Dekonposition sind nit Abstraktionen verbunden, ‚denen sich der 
Entwickler mehr oder weniger bewußt ist. 


Nachfolgend werden einige Gesichtspunkte: der Abstraktion 
angegeben, die bei der’ Aufgliederung eines Softwaresysteas in der 
Entwürfsphase von Bedeutung sind.n. Außerdea .werden eine 
Darstellungsnöglichkeit für die Systenarchitektur aufgezeigt und 
Werkzeuge für die Realisierung ‚entsprechender Strukturen in 
Assenblersprache vorgeschlagen. | 


Die Autoren sind sich der Vorteile bewust, die höhere 
Progranniersprachen "gegenüber der Assenblersprache bieten. 
Tatsächlich. verwendet und empfiehlt man die Assenblersprache /6/ 
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bis auf den heutigen Tag für die Entwicklung und Weiterentwicklung 
von Betriebssystenkonponenten. Durch die Erweiterung der 
Assemblersprache un entsprechende Makros in VerbindunJ nit 
entsprechenden Programnierhilfen.lassen sich alle wesentlichen, 
mit den modernen Programmiersprachen entstandenen Strukturen 
anwenden. 


2. Abstraktionen in der Entwurfsphase 


Der Entwurf eines Softwaresystens wird in 3 Schritte gegliedert: 
(1) Systeaspezifikation erarbeiten 
(2) Systemarchitektur festlegen 
(3) Algorfithmierung. 


Der erste Schritt für den Entwurf eines Softwaresystens ist eine 
möglichst vollständige Beschreibung des Verhaltens des 
beabsichtigten Systens in der definierten Ungebung. Diese 
Beschreibung wird auch als Systenspezifikation bezeichnet und 
könnte in Fora einer Anwenderbeschreibung erstellt werden (Stufe 
E2 der PwT-Entwicklungsnoaenklatur}) . Die Systeaspezifikation ist 
in wesentlichen verbaler Art, sollte jedoch weitestgehend durch 
foraale und graphische Darstellungen unterstützt verden (forzale 
Syntaxbeschreibung,-natheratische Funktionen, Ablaufpläne,...). 
Mit der Systenspezifikation liegt fest, was Jas geplante Systen 
leisten soll. Die Systenspezifikation abstrahiert davon, sie die 
entsprechende Systerleistung realisiert werden kann (eigene 
Algorithren und Daten sowie Nutzung der Umyebung) . 


Der nächste kntwurfsschritt besteht iz Entwickeln der 
Systenacchitektur. Dabei wird Jas vesaatsysten in Teilsysteze 
aufgeteilt. Diese Teilsystene werden als Moduln bezeichnet. Zur 


Beschreibung eines Moiluls gehörten die ia nachfolyenden Bild 
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u S 


angejebenen Informationen. Die Semantik der Funktionen’ und Daten 
wird in /V/ ars Intended State Machines (154) bezeichnet. 


-. A 
| Modulnane BE | 
a Al en Een eh en me ee Er Fa ee 
t verfügbare ° | Semantik der I.) (2, 
. Funktionen Fusktionen bzw. e 
1} und Daten Daten (ISM). l : (2) (3) 
| verwendete ?unktionen 
1 verwendete Daten 
‚Algorithsen | Datenstrukturen 
P—— [PP [121 + 


Entwur Architektur 


\ 1) Modulspezifikation | 
Gesaatentwurf 


Bild 1. Betfachtungsweise eines Moduls 


Einseitige informationelle Kopplung eines Moduls "wit seiner 
Umgebung werden in Bild 1 durch parallele gestrichene "und 
durchgehende’ Linien dargestellt. i 
; 
Das Gesantsysten ist vollständig aufgegliedert, wenn für alle 
Moduln die in Bild ) „genannten Inforaationen gewonnen sind.- 
w 

Das Kriteriua ‚dafür, daß eine gewisse. Menge von ‘Einheiten 
(Funktionen, Daten) zu einen Modul zusammengefaßt werden, sind 
bestimate, ia betrachteten Zusamaenhang -vwesentliche geaeinsane 
Eigenschaften der Einheiten. In diesen allgemeinen Sinne werden 
auch ADA-Packages gebiliet /U/. i i 
Das Problen dieser Aufgliederung besteht darin, die ‚für die 
Architektur wesentlichen Gesichtspunkte zu erkennnen. Die 
Aufgliederung sollte adäquat jen zu Lösenden Problemen erfolgen. 
Erfahrungsgemäß wirkt sich eine. ungünstige 'Systemarchitektur weit 
negativer auf die Qualität -des Gesäatsystens aus, als Mängel bei 
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der Realisierung. Realisierungsmängel lassen sich auch! einfacher 
beheben. ... PIE REEIE EN ar: >“ ak 


Für die Entwicklung der Systemarchitektur aibt es kein 
allgeneingültiges Rezept. Folgende Gesichtspunkte erscheinen 
vesentlich: 


(1) Funktionelle Aufgliederung r 
Ein System kann entsprechend $Jeinean Verhalten- (IS4) in eine 
Menge von Teilfunktionen aufgeteilt “grden. Die 
Teilfunkionen liefern jeweils einen Beitrag zur Realisierung 
der Gesaatfunktion. Diese funktionelle Aufglieäderung wird 
soweit getrieben, bis üUnfang und Kompliziertheit der 
Funktionen sinnvoll erscheinen. 

(2) Aufgliederung nach Dateastrukturen 
Wesentliche Daten, von nichttrivialer Struktur bilden 
zusamaen mit den auf diese Daten definierten -Punktionen eine 
abstrakte Datenstruktur, d.h. Abstraktion von der konkreten 
Struktur der Daten und von der Realisierung. der 

t entsprechenden Zugriffsfunktionen. Durch die Lakalität der 
Datenstrukturen ergeben sich die bekannten 
Zuverlässigkeitsvorteile,. 

(3) Abstraktion von Eigenschaften der Uagebung 
Jedes Softwareprodukt arbeitet in einer bestiasten Uagebung. 
Die Inforaationen über die Umgebung sind in der 
Anwendungsprograanierung iesas in die Frogfranniersprache 

% integriert. Die Prograasiersprache enthält alle Funktionen 
der Ungebung, ‘die ein Prograsma nutzen kann. Konponenten eines 
größeren Systens aüssen die Funktionen der Umgebung durch 
geeigneten Aufruf nutzen. 

Eine Koaponente kand weitjeheni _von den Eigenschaften 
unabhängig gestaltet werden, indea zwischen Komponenten .und 
Umgebung eine Schnittstelle definiert wird /5/. Nenntaig von 
der Uagebung ernalten ausschließlich yewisse 
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Schnittstellenaoduln. Durch. ‚diese werden Sie. Auforierungen* 
der Sikeprechenden kompenenten- an--.die Umgebung in’ die 
funktionellen. 3öglichkeiten der. "konkret vorhandenen Unyedung 
transforaiert. 
wenn die <omponenta.in einer 'anleren Jayebung- genutzt “erden 
soll, sind- "die. Schnittstelienäoduln zu .änderns 'bieser 
Gesichtspunkt. der Abstraktion iIrt für Assenblerprogtaaae von“ 
+ besonderer Bedeutung. e 
{4) Ablaufsteuecung ö a 
Inter *Ablaufsteuerung wird die :Aufruffolye der einzelnen 
Moduln verstanden. Es: solite zunächst imaer- "eine 
hieratchische Grundstruktur- der Ablaufsteuerung angestrebt 
werden. "Ein -Modul ruft Funktionen hieracchisch 
"nachyeötdneter' Noduln auf. Nach Beendigung ‘der. aufyerufenen 
Funktion geht die Steuerung an den rufenden Modul. zurück... 
“Die hierarchische. Srundstruktur air durchbrochen, “enn 
mehrere Funktionen zu einea Modul zusammengefaßt werden. In- 
diesen :Fällen bleibt die Ablaufsteuerung lineac, ist aber 
nicht aehr ’hierarchisch. 
In weiteren Fallen: a 
vr Fehlerbehandlung (Spezialfall: äbbruch’ nacı Fehler) 
rekursive: Problene (z.B« Koanandointerpreter) 
Ä 
ist sogar eine nichtlineare Ablaufsteuerung der Probleslösung 
adäquat. “ ® 
(5) Modulgröße, Nodulkomaunikation. 
“ Die einzelnen Noduln sollten weder zu klein hoch zu groß 
sein. „zu kleine-Moduln haben. die Nachteile: 
= "Aufrufaufsand. kann. ins Gewicht fallen. 
1” Strukturbeziehungen zwischen den “oduln sind zu 
koaplex. 
‚Zu 'gtoßs Modulä haben "die Nachteile: 


- Moäulinhalt. ist zu ‚konplex und. unverständlich. 
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- übersetzungszeiten sind in der Testphase zu hoch. 
Das. .Problen besteht AJarin, einen-- sinnvollen Konproniß 
zwischen der Komplexität der Systeaacchitektur 
{Modulkonmunikation) und der Komplexität der Modulinhalte zu 
finden. i 


Man muß ein möglichst objektives Maß für die koaplexitat ier 
Systenarchitektuc und ‚der Modulınhalte fordern. Han könnte 
sich dabei an den Ergebnissen. in /7/ zur Prosrauskosplexität 
orientieren. U.a. wird dort das “a8 tschwierigkeitsjrad! 
eines Programaes aus der Anzahl der Operationen 'und der 
Anzahl der Operanden abgeleitet. 
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Es wiri foljenle Darst-lluny 


vorgeschlalen: 


Hieracchische örunlstzruztucr: 


tamnan nn nt 


yes -ans- + 
| 
| | | 
ters ent +. >=2> ==. too... tr 
N I t l ! I 
I I I En | | 
gassasaalsr ye-..-.-o.+ te----——o-r_ 


ms z-on.--t 


+ ..nn.-+ 


Bild 2. Darstellung der Systenarchitektur 


von “Modutlstrukturen 


ab-trakte. 


natenstLuKktur?: 


+, [rnR m nr 


Mehrfach 


genutzte Funktionen: 


4 --- nn 
= 
| I 


+, ,.n2....-+ 


Spezielle Moduln: 


4er, ac, -.+ 
--->| I---> 
| | 


ya=----..-t 


Es sollte zunächst eine hreiarchische srunastruktur angestrebt 


werden. Diese bildet sich aus einer Tenie von Funktionsmoduln, Jıe 
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“mehreren Stellen des Systens aufzurufen sind, sollten separat 
dargestellt werden. 


ia Sinne von Unterprogrammen genutzt werden. Moduln, die ‘an 


Die Sprachen Modula-2 und ADA lassen dem: Anwender beim Verknüpfen 
von Moduln (datennäßig und aufrufmäßig) größte Freiheiten. Diese 
Möglichkeiten enthalten die Gefahr, daß ein Netz von Beziehungen- 
zwischen den Moduln entsteht. Det Nutzer sollte auf 
eingeschränktere Möglichkeiten orientiert werden. Z.B. wäre ‚es 
sinnvoll, Daten nur in Aufrufrichtung zu exportieren und die 
umgekehrte Richtung zu verbieten. 


3. Realisierung in Assenblersprache 


Für. die speziellen Belange der Asserablerprögramaierung werden 
folgende Prinzipien bzw. Hilfsnittel vorgeschlägen: 


= Die üblichen Makros zur Strukturierten Programzierung. werden us 
folgende Hakros zum Bilden und zum Aufruf von Hoduln ergänzt: 


fktnane SUBR Punktionsmodul bilden. 


m en a m ann SD an En an an a an an a rn an a a a an nn En ai a m a A an an a a ann a en nn m 


celsnaae CLASS Klassennodul nit mehreren Funktionen bilden 


fktnanel SU3R Funktion °1 

fktnane2 SUBR Funktion 2 

SEHE DRCHNEÄR ENDE EHER ESEHEESERE IRRE. IENRBRERHDEIF SERESPRNSACRSERRINETIEEREN 
CALL fktnane Funktionsmodul aufrufen 


aD nn ann DEE On a a GE mE Gm ann a Ga m an ne a Er an En un a an ae An nn A En an En mn a rn a an a Ga de an aa a a nn 
- 


CLSCALL. clsnane, fktnane 
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ı 2 a 
Funktion in einen Klassennodul aufrufen 


Paraneterüpergabe bzw. datenkommunikation zwischen 
verschiedenen Moduln erfoigt über einen geneinsanen 
Datenmodul. Prinzipiell kann der Datenaustausch auch 
über Paraneterlisten erfolgen. Wegen des höheren 
Aufwandes, wird für die Kommunikation zwischen Moduln 
eines Teilsystens jedoch die Methode gemeinsaner 
Bereiche verwendet. 


Für den Pall, daß das entsprechende Softvaresysten 
reentrant sein soll teilen sich die Datenaoduln jn einen 
gemeinsamen RO-Datennodul und in einen RR-Datennodul. 
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Trautloft, R. 


Über einen Zugang. zur automatisierten Auswahl. physischer Reali- 
sierungen von relational definierten Bestandsdaten 

1. Aufgabenstellung 

Die hier vorzustellenden Ergebnisse entstanden im Rahmen von Ar- 
beiten, die. mit dem Ziel durchgeführt wurden, den Grad der Rech- 
nerunterstützung im Softwareentwicklungsprozeß (SEP) zu erhöhen. 
Dabei erfolgte eine Beschränkung auf. die für die Aufgabenklasse 
"nrogrammtechnische Versorgung für automatisierte Informations- 
systeme" relevanten Aspekte. Für diese Aufgabenklasse nimmt die 
Teilaufgabe "Projektierung der Datenbasis" eine Schlüsselstel- 
lung im SEP ein. Das ist zum einen bedingt durch den Aufwand bei 
der Lösung dieser Aufgabe, zum anderen durch den Einfluß des Pro- 
jektierungsergebnisses auf das Leistungsverhalten des entwickel- 
ten Softwaresystenms in der Nutzungsphase. 


In Abb. 1 ist ein Ausschnitt des SEP sowie die Einordnung mar- 
kanter Entwicklungsstadien der Datenbasis dargestellt. 


nen S -- - - - - --Problemstrukturen 
--.-.-- - -- = --- - —Modellstrukturen 
een ___ __ Inplenentterungs- 


Abb. 1: Entwicklungsstadien der Datenbasis im Verlaufe des 'SEP 


Die nachfolgenden Ausführungen beziehen sich auf den Aspekt der 
‚„rechnerunterstützten Realisierung der Transformation von Modell- 
strukturen (M-Strukturen) in Implementierungsstrukturen (I- 
Strukturen). 
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2. M-Strukturen 

Die in der 'Entwurfsphase des SEP zu realisierende Modellbildung 
wird durch die, zur Verfügung stehenden sprachlichen Mittel be- 
einflußt. Die eingangs erwähnten Arbeiten haben, basierend auf 
der Programmiersprache PASCAL, zu einem Entwurfsbeschreibungs- 
mittel geführt, das sich bezüglich der logischen Datendefini- 
tion am CODD'schen relationalen Datenmodell und bezüglich der 
Manipulation der so definierten Daten an der Sprache SEQUEL 
orientiert. Damit ist im Gegensatz zu den anderen bekannten Da- 
tenmodellen die Möglichkeit gegeben, streng zwischen logischer 
und physischer Datenbeschreibung zu trennen, d. h. in der Ent- 
wurfsphase implementierungsunabhängig zu arbeiten. 


Für die Beschreibung der’Datenbasis sind die M-Strukturen vom 
Typ TUPELSET und vom Typ RELATION von Interesse. Sie basieren 
beide auf dem TUPEL-Typ. Informal läßt sich dieser wie folgt 
charakterisieren: 


- die Komponenten eines Tupels heißen Attribute 

- Attribute sind vom einfachen Typ 

- die Attribute eines Tupels setzen sich aus zwei disjunkten 
Teilmengen zusammen, der Menge der Schlüsselattribute und der 
Menge der Nichtschlüsselattribute. 


Beispiel: 
TYPE ANGEST = TUPEL [PERSNR:INTEGER] OF (NAME:ALPHA(15); 


‚ VNAM:ALPHA(8) ; PLZ:INTEGER;ORT:ALPHA(15)); 
VAR PERS: TUPELSET OF ANGEST; 


Es existiere weiter 
VAR FORSCH: TUPELSET OF THEMA; 
zur. Charakterisierung der Forschungsthenen einer Einrichtung, 


dann 158t sich die Mitarbeit der Angestellten an einen oder 
mehreren Forschungsthemen durch die Vereinbarung 


VAR ARBEIT: RELATION PERS WITH FORSCH OF THEMMIT; 


beschreiben, wobei THEMMIT als Typ beispielsweise wie folgt 
vereinbart worden sei: 


TYPE THEMMIT = TUPEL [PERSNR:INTEGER;THNR:ALPHA(5)] OF 
(VBE<REAL); 
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3. Automatisierungsansatz 

Das Ziel besteht darin, die mit den eben vorgestellten sprach- 
lichen Mitteln beschriebenen M-Strukturen in I-Strukturen der 
Basismaschine zu transformieren. Der Begriff der I-Struktur soll 
hier nur kurz mit dem Verweis auf Ähnlichkeit mit den häufig ver- 
wendeten Begriffen Speicherstruktur und Speicherzuordnungsstruk- 
tur eingeführt werden. Die Automatisierung dieses geistigen, im 
allgemeinen hochgradig kreativen Prozesses läßt sich als Lösung 
eines Auswahlproblems realisieren.. Jede Implementierungsvariante 
D der Datenbasis besteht aus n I-Strukturen Kıjr d. h., die ‚i-te 
M-Struktur wird durch die I-Struktur j implementiert. Dabei steht 
für die i-te M-Struktur ein I-Struktur-Vorrat von m; I-Strukturen 
zur Verfügung: 


D ={K,li = 1(1)n, Vi: 1Jeft,...m;,}} 


Gesucht wird diejenige Implementierungsvariante, für die eine ge- 
eignete Bewertungsfunktion f. Extremaleigenschaften besitzt: 


rk, ,) = extr 


Bei der Herleitung einer solchen Bewertungsfunktion bieten sich 
die Belastungsgrößen für die in der Nutzungsphase eingesetzten 
Ressourcen der EDVA als Auswahlkriterium an. Für die Software- 
systeme der betrachteten Aufgabenklasse sind der extern belegte 
Speicherplatz (S) und die Zahl der notwendigen externen Zugrif- 
fe (2) zur Erfüllung der operationellen Anforderungen an die Da- 
tenbasis aussagekräftig für: die Bewertung von I-Strukturen. 


Die Verwendung solcher Bewertungskriterien impliziert die Not- 
wendigkeit, Voraussetzungen -für deren Quantifizierung zu schaf- 
fen. Zur Analyse der zu erwartenden operationellen Anforderun- 
gen an die I-Strukturen im Verlaufe der Nutzungsphase ist es 
möglich, eine Menge von elementaren Verarbeitungsoperationen an- 
zugeben, auf die alle relevanten Anweisungen des Entwurfsbe- 
schreibungsmittels zurückzuführen sind. Sie setzen sich aus Re- 
trieval- und Update-Operationen zusammen. Weiter kann jede I- 
Struktur durch zwei analytische Modelle charakterisiert werden: 


- Modell der Speicherplatzbelegung 
- Modell des Zugriffsverhaltens in Abhängigkeit von der elenen- 
taren Verarbeitungsoperation. 
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Die durch konkrete Anforderungssituationen - beschrieben durch . 
elementare Verarbeitungsoperationen - parametrisierbaren ana- 
lytischen Modelle liefern somit eine quantitative Bewertung der 
I-Strukturen bezüglich der Kriterien S und Z. Die Formulierung 
eines Entscheidungsmodells zur Auswahl einer Implementierungs- 
variante, der Datenbasis ergibt: 


- Es existieren zwei Bewertungs- oder Gütekriterien (S, 2). Für 
beide ist ein Minimum anzustreben. 
- Es existieren mehrere Steuergrößen: 
das externe Speichermedium 
die Realisierung des Primärzugriffspfades 
die Realisierung des Sekundärzugriffspfades. 
- Die Abhängigkeit der Gütekriterien von den Steuergrößen ist 
durch die analytischen Modelle beschrieben. 


Damit liegt eine Polyoptimierungsaufgabe vor 1). 


Zur Lösung der Polyoptimierungsaufgabe wurde: ein heuristisches 
Lösungsverfahren gewählt. Die Hauristik wurde abgeleitet aus 
der Vorgehensweise des Softwareentwicklers im konventionellen 
SEP und basiert wesentlich auf der Ausnutzung der beiden Fakten: 


- Antinomie zwischen S und 2 

- Die Abarbeitungsfreundlichkeit eines Softwaresystens steigt 
mit dem Sinken der Zahl der benötigten externen Speicherge- 
räte. 

Zur Vorgabe eines Lösungsbereiches wird im Dialog der Software- 

entwickler einbezögen. 


4. Programmtechnische Realisierung „ 

Abb. 2 zeigt die Struktur eines entwickelten Programmsystens, 
das den oben erläuterten Ansatz realisiert. Als-Darstellungs- 
mittel wurde ein Strukturdiagramm (nach CONSTANTINE "structure 
chart") verwendet. Es zeigt die als externe Prozeduren geschrie- 
benen Bestandteile, ihre Steuerflußbeziehungen untereinander so- 
wie die über Parameterübergabe realisierte Datenkopplung zwi- 
schen ihnen. Das Programmsysten umfaßt ca. 2500 Zeilen PASCAL- 
Text. 

Sowohl bei der Formulierung des Automatisierungsansatzes als 
auch bei der programmtechnischen Realisierung wurde besonderer 
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Wert auf Erweiterbarkeit gelegt. Durch die Herleitung entspre- 
chender analytischer Modelle ist der in die Auswahl einbezogene 
I-Struktur-Vorrat erweiterbar. 


Für den: Nachweis, der Adäquatheit der zahlreichen Modellbildungen, 
auf denen der Automatisierungsansätz basiert, wurden einige I- 
Strukturen für eine über VSAM verfügende Basismaschine modelliert. 


> 


OPTIMUM. 


Abb. 2: Strukturdiagramn des Programmsystens 


5. Schlußbemerkungen 

‘Die programmtechnische Realisierung ‘weist die Anwendbarkeit des 
Automatisierungsansatzes nach. Damit wurde eine wesentliche Vor- 
leistung für eine in ein Systen zur rechnerunterstützten Entwick- 
lung von Softwaresystemen (der gegebenen Aufgabenklasse) /2/ in- 
tegrationsfähige Komponente erbracht. 


Außerhalb eines solchen Systems könnten die erzielten Ergebnisse 
die Basis bilden für die Entwicklung eines autonom nutzbaren 

Werkzeuges für den SEP. Dieses Werkzeug stände als Entscheidungs- 
hilfe für den Softwareentwickler zur Verfügung und würde die für 
andere technische Entwicklungsprozesse typische und bewährte Ar- 
beitsweise des Ingenieurs mit dem Variantenvergleich ermöglichen. 
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Experimente mit der Programmiersprache CDL2 


1. Einleitung 


Die Programmiersprache CDL2 wurde als Hilfsmittel zur Implemen- 
tetion von Compilern entwickelt /1, al. Sie hat sich dabei bestens 
bewährt. Naturgemäß ist jedoch auch ihre Verwendung als Ausgangs- 
punkt für das syntax-orientierte Programmieren überhaupt, wie es‘ 
durch die Jacksonsche Entwurfsmethode empfoilen wird /3/. Im fol- 
genden Vortrag wird aus einem der Standardbeispiele. aus der Welt 
der Jacksonschen Entwurfsmethode ein CDL2-Programn hergeleitet. 

Es zeigt sich, daß bereits in einem sehr frühen Entwurfsstadium 
verarbeitungsfähige CDL2-Programme entstehen. CDL2 erweist sich 
dabei gleichsam als ein Werkzeug zum programmiersprachlich ge- 
führten top-down-Entwurf. 


2. Aufgabe /4/ 


"Bine Lochkartendatei ist aufsteigend sortiert nach einem Schlüs- 
sel, der in jeder Karte enthalten ist. Innerhalb dieser Reihen- 
folge ist die erste Karte jeder Gruppe mit einem gemeinsamen 
Schlüsselwort ‘eine Kopfkarte, die restlichen sind Detailkarten. 
Jede Detailkarte enthält ein numerisches Betragsfeld. Es soll 

ein Bericht erstellt werden, der die Gruppensumnen für alle 
Schlüsselworte ausweist". 


3. Jacksonscher Entwurf 


Es wird eine formale Beschreibung der Eingabedatenmenge und 
eine formale Beschreibung der Ausgabedatenmenge benötigt. Der 
Programmentwurf besteht darin, Beziehungen zwischen Eingabebe- 
schreibung und. Ausgabebeschreibung herzustellen. 


Beschreibung der Eingabedaten: 


card file: group, *. ! 
group: key card, group tail. 
key card: „ 4Test auf Schlüsselkarteff 
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group tail: detail card, . 
detail card: „ #Test auf Detailkarter 


Beschreibung der Ausgabedaten: 


report: title, report tail, 

title: ‚ #irgendeine Überschriftit 

report tailı line, =. 

iine: initialize, result, = 
initialize:s . #Bestimmung eines Anfangmwerts# 

result: accumulate, 

accoumulate: „ #irgendeine Verknüpfung? 


Zur Verbindung von Eingabedaten und Ausgabedaten werden folgende 
Verbindungsoperationen benötigt 


(a, ident, b): Identifiziere die Variable a aus der Eingabedaten- 


beschreibung mit der Variablen b der Ausgabedaten- 
beschreibung 


(, incl, b): Die Variable b der Ausgabedatenbeschreibung wird 


ohne Bezug auf die Eingabedaten in das Entwurfs- 
produkt einbezogen, 


(a, veq, b): Das entworfene Programm enthält die Variable a 


der Eingabedatenbeschreibung und die Variable b 
der. Ausgabedatenbeschreibung einzeln in der Rei- 
henfolge a vor b, 


Ausgehend von den Datenbeschreibungen des Beispiels werden als 
Variablenverbindungen vorgesehen 


(card file, ident, report) 

(, inol, title) 

(, incl; report tail) 
(group, ident, line) 
(key card, seq, initialize) 
(group tail, ident, result) 
(detail card, seq, accumulate) 


Dareus entstehen unmittelbar eire eingabeorientierte und eine 
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ausgabeorientierte Fassung des entworfenen Programs. 


Eingabeorientierte Fassung: 


card file: title, report tail. 

title: . 

report tail:' group, ® . 

group: key card, initialize, group tail. 
key card: 

initialize: . 

group tail: detail card, accumulate, #. 
detail card: 

accumulate: 


Ausgabeorientierte Fassung: 


report: title, report tail. i 
title: . ; 

report tail: line, ® « 

line: key card, initialize, result. 

key card: ; 

initialize: . 

result: detail card, accumulate, #® . 

detail card: 

accumulate: 


Beides sind bis auf etwas "CDL-Zucker" fertige verarbeitungsbe- 
reite CDL-Programme. 


Es müßten sich Entwurfsschritte zur Dateibehandlung, eof-Test, ı 
Fehlerbehandlung und zur Festlegung der Verknüffungsoperationen 
anschließen, 


‚4. CDL2 Fassung des Programs 


Für die eingabeorientierte Fassung des Programms wird ein voll- 
ständiges Programm angegeben, E3 enthält im Abschnitt mit der Be- 
zeichnung basic einen Testrahmen,. Das obige Entwurfsprodukt fin- 
det man im Abschnitt 'S, 


LAYER 1. 
SECTION basic, 
EXT is, zero, one, 
CONST zero=63, one=64, 
VAR first character, 
PREDICATE is +>x: equal+x+first character, next card. 
ACTION nextcard: newline+input, 
outchar+output+first character, 
newline+output, 
: inchar+input+first character, 
CONST input=0, output=10, 
ACTION inchar+ > channel+x>= 
"ZLST EXTNCALL BT INCHAR", 
ACTION outohar+>channel+>x= 
"ZLST EXTNCALL ZT OUTCHAR"; 
ACTION newline+>channel= 
NZLST. SLR gT ugn, NY, 
PRELUDE inchar+input+first character, 
ENDSEC basic, R 
SECTION Ss. 
INV is, zero, one, 
ACTION card file: title, report tail, 
ACTION title: „ 
ACTION report tail: group, s; . 
PREDICATE group: key card, initialize, group tail. 
PREDICATE key card: is+key, 
CONST key =one, 
ACTION initialize: . 
ACTION group tail: detail oerd, accumulate, #;. 
PREDICATE detail card: istdetail. 
CONST detail=zero,. 
ACTION accumulate:, 
ROOT card file, 
.ENDSEC s, 


ENDLIAY 1, 
PRELUDE basic. 
ROOT Ss, 


219 


Auszüge aus dem Drückprotokoll des CDL2-Compilers von 
KU Nijmegen Version 8,1. (79-05-03) belegen das Testergebnis: 


DIAGNOSTICS FROM PHASE 1 
sur O0 SEVERE ERROR(S) 
+++ 0 ERROR(S) 
-- 0 WARNING(S) 


DIAGNOSTICS FROM PHASE 2 
x### O0 SEVERE ERROR(S) 
+++ 0 ERROR(S) 
-- 0 WARNING(S). 


oo0oo0o-0o0- 
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MODULARE PROGRAIHIERUNG I PASCAL (Kurzfassung) 


Die Programmiersprache PASCAL /1/ besitzt außer dem Prozedur- 
konzept *einerlei Möglichkeiten zur modularen Strukturierung 
von Programmen, wie sie in neueren Programhmiersprachen 
bestehen, 

So. verftigen z.B. Ada /2/ und Modula-2 /3/ Über die Ausdrucks- 
mittel des package und des module, die äußerlich eine Samn- 
lurg von Definitionen und Deklarationen darstellen. lit Hilfe 
dieser Mittel kann u.a. das Prinzip des abstrakten Datentyps 
/4/ realisiert werden, indem eine Menge von verwandten Opera- 
tionen und die gemeinsame Datenmenge, Über der sie operieren, 
zusemmengefäßt werden. 

Die Zielstellung bestand nun darin, diese modularen Konzepte 
durch elre geeignete Software-Unterstützung in die PASCAL- 
Progremmierung einzubeziehen, Hierzu wird eine Spracherweite- 
rung von PASCAL, M-PASCAL, vorgeschlägen: PASCAL wird um das 
Hodule=-Konzept von Modula-2 erweitert, 

Zur Unterstützung von K=PASCAL wurde ein Precompiler, der 
M=PASCAL in PASCÄL überführt und ein Compiler für M-PASCAL 
implementiert. 
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Syntaxorientierter Programmeditor für PAS AL 


1. Einleitung 
An der Sektion Mathematik, Bereich IV, laufen. zur Zeit Arbel- 


ten an einem Softwarelabor für die Programmiersprache PASCAL, 
Als erste Teilaufgabe wird ein syntaxorientierter Programm- 
editor für PASCAL realisiert. In Ergänzung zu den üblichen 
Funktionen eines Texteditorse können durch einen syntaxorien- 
tierten Progranmeditor folgende Aufgaben realisiert werden: 

- Syntaxkontrolle 

- Adressierung fehlerhafter Syntaxeinheiten(Zeilen) 
Anfertigen von Strukturübersichten 

- formatierte (Quelltextausgabe 

- komplexe Operationen mit Syntaxeinheiten 
Es erfolgt keine Syntaxführung des Nutzers wie 2.B. in /1,2/. 
Syntaxkontrollen erfolgen nur auf Kommando des Nutzers. Die 
Realisierung greift auf einige Ideen aus /3/ zurlick (Aufbau 
eines Syntaxbaumes) und kann in einigen weiteren Punkten mit 
/4/ verglichen werden. Die Implementation erfolgte in PASCAL. 


Die Nutzung im TSO des 0S/ES für Quelltextblicher bis 800 Zei- 
len Länge ist bis Ende 1982 vorgesehen. Eine Überführung auf 
K1620 und K1520 ist für das erste Halbjahr 1983 geplant. 


2. Arbeitsweise des Editors 
Symtaxorientierte Editoren sind für die Dialogarbeit bestimmt. 
Für die Auswahl von Syntaxeinheiten benötigt der Nutzer lau- 
fend Informationen Über die. aktuelle Struktur des editierten 
Quelltextes, So sind folgende Dialogschritte vorgesehen: 

- Ausschrift über die Struktur des Programms 

- Adressierung einer zu bearbeitenden Einheit 

- Änderungen an der ‚aäressierten Einheit 
Naoh jedem Kommando erfolgt eine Ausschrift, die sowohl als 
Adressierungshilfe als auch zur Kontrolle der richtigen 
Funktion des vorangehenden Kommandos gedacht ist. 
Die zur Verfügung gestellten Kommandos untergliedern sich in 
fünf Gruppen: 
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1. Adressieren einer neuen Einheit 

2. Eröffnen bei. Abschließen’von Syntaxeinheiten zum 
Editieren 

3. Ändern des Inhalts der editierten Syntaxzeinheit 

4. Textoperationen 

5. Analyseoperationen 


Die Möglichkeit, das Editieren auf einzelne Syntaxeinheiten 
einzuschränken, soll in Verbindung mit der strukturierten 
Frogrammierung die Bildschirmarbeit ‘übersichtlicher machen 
helfen. 


3. Einheiten, Folgenummern 


Einheiten, die sich durch den Editor adressieren und bearbei- 
ten lassen, sind ausgezeichnete Syntaxeinheiten und Zeilen. 
Bei den ausgezeichneten Syntaxeinheiten wird unterschieden 
zwischen: 
1. zusammengesetzten Syntaxeinheiten; 
Program, /Prozedur, Funktion, Modul (Erweiterung ent- 
sprechend /5/): 
2. elementaren Syntaxeinheitenr 
Köpfe der zusammengesetzten Syntaxeinheiten (sinschließ- 
lich der Markendeklaerationen), Konstanten-,Typdefini- 
tionsteile, Variablen-, Rontinsndeklarationsteile und 
Verbundanweisungen 


Die elementaren Syntaxeinheiten sind für den Editor Zeilen- 
folgen. Die zusammengesetzten Syntaxeinheiten sind Folgen der 
unmittelber enthaltenen Syntaxeinheiten. 

Zeilenfolgen und Syntaxeinheitenfolgen werden mit 1 beginnend 
durchmumeriert. . Die zugeordneten Nummern heißen Folgenummern. 
Die Folgenummern dienen als Adressierungshilfe. Wach jeder 
Änderung werden sie neu zugeordnet und durch die Ausschrift 
des Editors sichtbar gemacht. Zur Bezeichnung der zusammen- 
gesetzten Syntaxeinheiten wird der'Name der Syntaxeinheiten 
benutzt, sonst das erste Morphen. 

Es sei das folgende Programm gegeben: 


PROGRAY. SUNME(INPUT,OUTPUT); 
VAR 1,J,SUMM:INTEGER; 
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BEGIN 

READLSCINPUT,T}; 

FOR Jr=1 TO I DO SUMM:=SUNM4T;- 

WRITEIN(.' "SUNME DER ZAHLEN VON 1 BIS',1:3,' =',SUMM:6); 
END; 


Das Progremm SUNME ist eine zusammengesetste Syntaxeinheit. 
Es besteht aus der Folge der elementaren Syntaxeinheiten 

1-PROGRAM, 2_VAR, 3_BEGIN 
Der duroh 3_BEGIN bezeichnete Verbund besteht aus der Folge 
der Zeilen 

1_BEGIN 

2_  _READLN(INPUT,I); 

3_ FOR .. 

4_ WRITEIN... 

5_END. 
(Das an die Folgenummern angefügte '_' Zeichen macht diese als 
Folgenummern'kenntlioh. ) 


4. Adressierung von Einheiten 
[ . 


Die Adressierung von Einheiten erfolgt nach dem Kursorprinzip. 
Der Nutzer gibt die Nummer einer Einheit an. Der Editor ord- 
net der adressierten Einheit in der Ausschrift '++' zu und 
macht sie so kenntlich, Durch die Eingabe von Rull kann der 

Kursor vor die erste Einheit gesetzt werden. 

Beispiele: 

Adressierung der 2.Einheit im Programm SUNME 

74 

1_PROGRAM, +++VAR, 3_BEGIN 

(Die Eingabe des Nutzers wurde unterstrichen. ':' zeigt dem 
Nutzer eine Kommandoanforderung.) 


Adressierung der 3.Einheit im Verbund, wenn der Verbund die 
editierte Einheit ist 


2_ _READLN(INPUT,T); 
+++ FOR... 
4_ WRITELN, .s. 
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Die Ausgabe des Kontextes der adressierten Einheit erleich- 
tert-die Kontrolle der-Adressierungsoperatiohen. 
Weitere Kommandos zur Adressierung sind: 

(+/-) [n] Vor- bzw. Zurücksetzen des Kursors um n bzw. 


3 Einheiten 
Beispiele: 
+4  Weitersetzen um 4 Einheiten 
- Zurlicksetzen um 3 Einheiten 
5, Eröffnen von Einheiten zum Editieren und Absahließen der 
Einheiten 


Nach dem Aufruf des Editors kann durch das Kommando INPUT 
ein Quelltextbuch eingelesen werden, das vorher dem PRD-File 
zugeordnet wurde. Es erfolgt nach disser Eingabe eine Struk- 
turanalyse und Ausgabe einer Übersicht über die Syntaxeinhei- 
ten auf dem äußersten Niveau. Erfolgt z.B. die Eingabe des 
Programms SUNME vom PRD-File, so gibt der Editor als erstes 
folgendes aus: 

I SUMME.1_ 

+++ PROGRAM, 2_VAR, 3_BEGIN 

Es ist die umfassendste Syntazeinheit zum Editieren eröffnet. 
Die erste Einheit ist edressiert. Die enthaltenen Einheiten 
können im Direktzugriff als unzerlegbare Einheiten Über die 
Folgenummern wie Zeilen in Texteditoren ersetzt, gelöscht, 
an eine andere Stelle transportiert werden usw. Soll jedoch 
der Inhalt der Einheiten schrittweise verändert werden, 50 
sind Syntaxeinheiten zum Editieren zu eröffnen. Nach dem 
Eröffnen wird eine Information über die Folge der darin ent- 
haltenen Einheiten ausgegeben, die nun durch den Editor an- 
zusprechen sind. 

2.B. läßt sich nach der obigen Ausgabe der Verbund zum Edi- 
tieren eröffnen: 

de 

I SUMM.BEGIN.1_ 

+++ BEGIN er 

2, READLN(INPUT,I); 

3: FOR J:s=1 TO I DO SUNN:=SUNK+J; 

Durch das Kommando 3. wurde die 3.Einheit adressiert und zun 
Editieren eröffnet. Ein zeilenweises Editieren des Verbundes 
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ist nun möglich. i 
Zum Abschließen von Syntaxeinheiten existiert das Kommando 'x'. 
‚Bei Forsetzung. des Beispiels mit dem Kommando 'x' ergibt sich: 


ıx 
! SUMM.1_ 
+++ PROGRAM, 2_VAR, 3_BEGIN 


Die editierte Einheit wird abgeschlossen. Das Editieren der 
umfassenden Einheit FaBt. sich fortsetzen, 
Der Editor gipt zur besseren Orientierung bei diesen Opera- 
tionen zusätzlich die Namen der umfassenden Syntaxeinheiten 
eus. \ 
Zum AÄbschließen mehrerer umfassender Syntaxeinheiten wurde" 
das Kommando 

« Name 
implementiert. Es werden alle.umfassenden Syntaxeinheiten ein- 
schließlich der Syntaxeinneit mit dem angegebenen Namen ab- 
geschlossen. Wird die umfassendste Syntaxeinheit (z.B. das 
Programm SUMME) abgeschlossen, so ist das Editieren beendet. 
Es erfolgt eine Ausgabe des Quelltextes auf das zuzuoränende 
PRR-File. 
(Für ..die Dialogeingabe eines Quelltextes ist das Kommando 

:=TE zu verwenden, vgl. Abschn.6.) 


6. ändern des Inhalts der editierten Syntaxeinheit 


Jede editierte Syntaxeinheit besteht aus einer Folge von 
Syntaxeinheiten oder Zeilen. Objekt einer Operation kann eine 
Einheit ‘(gegeben durch eine Folgenummer) oder eine Teilfolge 
von Einheiten sein. An Operationen sind zulässig: 


0BJ1:=0BJ2 Wertzuweisung 
OBJ1:=! Löschen 
OBJ1£=0BJ2 Transport von OBJ2 auf die Stelle von OBJ1 
OBJ1C=>0BJ2 Vertauschen 
ORBJI #0RJ2 Verkettung 
Kodierung der Operanden: 
leer adressierte Einheit 
n1..n2 Folge der. Einheiten n!1,...,n2 


n n-te Einheit 
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Ein einzugebender Operand wird durch TE symbolisiert, 

Nach jeder OMperation wird ein überschriebenes-Objekt im Be- 
reich SAVE gerettet. Durch SAVE l1&ßt eich dieses Objekt im 
folgenden adressieren. TE und "SAVE sind nur als OBJ2 zulässig. 
Bei der Verkettung wird die Stelle vor der ersten Einheit 
durch Full adressiert. " 

Beispiele für Kommandos: 


2:=! 2,Einheit löschen 

1#SAVE gerettete Einheit wieder einfügen 

1c=4 4.Einheit an die Stelle der ereten Einheit 
transportieren 

2«>3..4  2,Einheit hinter 4,Einheit transportieren 

2:=TE 2,Einheit durch einzugebenden Text eraetzen 


Die Texteingabe beginnt nach der Ansschrift 

I WRITE TEXT UNTIL/ x 
und endet nach der Eingabe von / x am Anfang einer neuen 
Zeile, 


T. Textspeicher 


Um komplexe Vmatrukturierungsoperationen an Programmen aus- 
führen zu können (wie sie z.B, bai größeren Änderungen erfor- 
derlich aind), wurden drei Textepeicher zur Verfügung gestellt. 
Sie tragen die Bezeichnungen 

TEXT], TEXT2, TEXT3. 
Alle Editieroperatipnen, die für Programme vorgeaehen sind, 
können nach dem Eröffnen -einep Textspeichers zum Editieren 
(Rommanda TEXTI oder TEXT2 bzw, TEXT3) auch auf den im Text- 
speicher enthaltenen Text bzy. enthaltene Folge von Syntax- 
einheiten angewendet werden. 
Alle Textspeicher können heliebig als Operand bei den Ändermgs- 
aperationen auftreten. i 
Beispiele; 
In TEXT1 ist eine neue Programmyersion eines bereits gelade- 
nen Progranmg zuysammenzustellen, Die Struktur des Programms 
wird durch die Ausschrift des Rechnere sichtbar; 
! BEISPIEL],1_ | 
+++ PROGRAM, 2_CONST, 3 _TYPE, 4,HILFSFROZ, 5_BEGIN 
Folgende Aktionen eind jetzt denkbar: 
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Eingabe des neuen Programmkopfes: 
:TEXT1:=TE 
! WRITE TEXT UNTIL / « 
1 PROGRAM BEISPILL2; 


Er 


Anfügen der 2. Syntaxeinheit des gegebenen Programms: 
:TEXT14#2 

Antügen der 4. und 5.Syntaxeinheit des gegebenen -Programms: 
: TEXT144..5 


Eröffnen von TEXT1 zum Editieren, um noch auszuführende Ände- 
rungen durchzuführen: 

:TEXTI 
Ausführung der Änderungen ... 
Abschließen von TEXTI (Das alte Programm wurde bisher nicht 
verändert): 

:* 

t BEISPIELI.A_ 

+++ PROGRAY, 2_CONST, 3_TYPE, 4_HILFSPROZ, "5_BEGIN 


Überschreiben des alten durch das neue Programm: 
:1..5:=TEXTI 

Abschließen des Editierens: 
ix 

Im Rahmen des noch zu implementierenden Softwarelabora ist an 

eine Globalisierung der Textspeicher gedacht, so das nach Ap- 

scnluß des Editors !n TEXT1 weiter die neue Programmversion 

zur Verfügung steht und über die Weiterverwendung (Speiche- 

rung) später entschieden werden kann. 


B. Textoperationen 


Jede vom Editor verwaltete Einheit besitzt als tert eine 
Quelltextzeile oder eine Folge von Quelltextzeilen. Es sind 
Operationen vorgesehen, mit denen man im Text einer Einheit 
einen Bezeichner oder eine Zeichenkette 

- suchen 

- beim ersten Auftreten ersetzen 

- bei jedem Auftreten ersetzen kann. 
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‘ls Kömmandoform ist vorgesehen: 
SEARCH Op 
(& TTER/AILTERGLL) Cp Cp 
Ein 'Operand Op hat die Forr: 
„Eezeichner oder 
z Text z2 mit z Zeichen # leer und Text Folge von Zeichen, 
die z nicht enthält. 
Für zrei aufeinenderfolgende Texte gilt: z TextiI z Text2 z 


Ein Bezeichner wird entsprechemdder FASCAL-Syntax im Text der 
adressierten Einheit gesucht (einschließlich der Yommentare, 
ce euch Kommentare auf die verwendeten Bezeichnungen Bezug 
nehnen). Hierdurch ist es z.P. möglich, einen RBezeichner A 
in einer Prozedur durch den Bezeichner ANFWERT an allen Stel- 
ı1en zu ersetzen, ohne daß in anderen Morphemen, die auch den 
Buchstaben A enthalten, eine Anderung bewirkt viird. 

(Könnendo ALTERALI A ANFWERT) 
Durch ‚des Komman’o 

ALTERALL/L/T./ 
ist es möglich, alle öffrenden eckigen Klammern durch die 
gleichwertige Zeichenfolge '(.'! zu ersetzen. 
Die SEARCH-Operation ist z.B. zum schnellen Fositionieren auf 
benannte Syntaxeinheiten geeignet: : 

SEARCH HIIPSPROZ 
würde nach dem Start des Editierens für das Programm. BEISPIEL1 
auf den Kopf der Frozedur EIIFSFROZ positionieren. 
9. Inalyseoperationen 
Als’ Analyseoperationen verden zunächst eine Strukturanalyse 
und der Syntaxtest realisiert. Die Strukturanalyse erkennt 
nur’ die nfänge der elementaren und nichtelementaren Syntax- 
einheiten (sofern sie am Anfang einer Zeile beginnen). Sie 
vird bei der Irogrammeingabe aufgerufen, um Strukturiber- 
sichten ausgeben zu können. Die Syntaxenalyse ruft der Eenut- 
zer durch das Kommando 

£ SYNTAX OBJ1 

auf, wobei CEJ1 wie bei den Änderungsoperationen definiert 
ist. Die Syntaxanalyse formatiert den Zuelltext so, daß jede: 
elementare und nichtelementare Syntaxeinheit am Zeilenanfengz 


beginnt, 
Strukturanelyse und Syntaxanalyse erkennen syntaktische Feh- 
ler und geben eine Fehlerliste aus.. lit Hilfe des Kommandos 

ERROR 
können später fehlerhafte Einheiten adressiert werden. Es 
wird nach diesem Kommando in der editierten Einheit der näch- 
ste einer Syntaxeinheit oder Zeile zugeordnete Fehler gesucht. 
Die Ausgabe des Editors nird nach dem Kommando ERROR außerdem 
um eine Übersicht über die Anzahl der enthaltenen Fehler 
erweitert. Z.E. könnte die Ausschrift nach dem Kommando ERROR 
die im folgenden Peispiel angegebene Form besitzen. 
Beispiel: 

ERROR 

! BEISPIEL3A24%%, 1 

1_ PROGRANRRORs®, +++ TYPEswins, 3_CONSTuslae,..5_ 

t 

xausx«xERROR 2 WRONG SEQUENCE OF SYNTACTICAL UNITS 
Das Programm BETSPIEL3 enthält vier Fehler. Davon ist ein 
Fehler im Konstantendefinitionsteil und ein Fehler im Varlab- 
lendeklarationsteil enthalten. Ein Fehler betrifft die Rei- 
henfolge der Syntaxeinheiten. Über den vierten Fehler erscheint 
aus Platzgründen keine Information. 
 126=3 (Vertauschen der beiden Syntaxeinheiten TYPE und 

CONST) 
1_PROGRAM, +++ CONST, 3_TYPE, 4_VAR, 5_BEGIN 
: ERROR (Auf das Kommando ERROR hin wird im Konstanten- 
definitionsteil der nächste Fehler gesucht) 

I BEISPIEL3gR3 4. CONSTmalar.2_ 

1_ .CONST 

+++ K:=3; 


KUNAXWERROR 10 EXPECTED 
3- MAX = 100; 


Durch wiederholtes Anwenden des Kommandos ‚ERROR ist es. mög- 
lich, nacheinander alle Fehler zu adressieren und zu besei- 
tigen. 


230 


10. Literatur 


/1/ Teitelbaum, R.T.: The Cornell program synthesizer: A mi- 
crocomputer implementation of FL/CS. Cornell University, 
Ithaca, New York, TR 79-370, 1979. 


/2/ Koster, C.H. u.a.s Software development in the CDI2 la- 
boratory. Sofware Engineering Environments, Procee- 
dings of the GMD Symposium in Lahnstein, North-Holland, 
1981, S.97-118. 


/3/ Donzeau-Gauge, V. u.a.: A structure-oriented program 
editor: A first step towards oomputer assisted pro- 
gramming. International computing symposiunm, 1975, 
North-Holland, 1975, S.113-120. 


/4/ Burkhard, H.: Konzepte zur Systematisierung der Benuzer- 
schnittstelle in interaktiven Systemen und ihre Anwen- 
dung auf den Entwurf von Editoren. ETH Zürich, 1981. 


/5/ Bothe, K.; Kosciolowicz, R.r M-PASCAL, Sprachbeschrei- 
bung. HU Berlin, Sekt. Math., Forschungsbericht, 1982. 


/6/ Paulin, G.; Schiemangk, H.: Programmieren mit PASCAL, 
Berlins Akademie-Verlag, 1981. 


Verfasser: 


Dr. sc. B. Hohberg 
Humboldt-Universität zu Berlin 
Sektion Mathematik 

1086 Berlin 

Postfach 1297 


231 
Kosciolowicz, Raimund 


j ee 
Konzeption eines Programmierlabors zur Unterstützung des 


modularen Programmentwurfs mit PASCAL 


1. Entwicklungsrichtungen der-Softwaretechnologie 


Unter dem Eindruck der Softwarekrise kam es in den 70er Jah- 
ren zu verstärkten Forschungs- und Entwicklungsaktivitäten 
auf verschiedenen Teilgebieten der Softwaretechnologie. Das 
gemeinsame Ziel war die Entwicklung von Methoden und Hilfs- 
mitteln zur Beherrschung der Probleme des Entwurfs, des 
Tests und der Wartung von Software, die Reduktion der Kon- 
plexität der Problemlösung und die Schaffung zuverlässiger 
und modifizierbarer Software mit Hilfe von leistungsfähigen 
Programniersystenen. Diese Entwicklung hat sich in den 
letzten Jahren besondere auf die weitgehende Unterstützung 
aller Etappen des Softwarelebenszyklus durch Programnier- 
systeme konzentriert und findet ihren Ausdruck in einer 

kaum zu bewältigenden Fülle von Veröffentlichungen. In den 
folgenden eng miteinander verbundenen Teilgebieten der Soft- 
waretechnologie wurden bisher bedeutende Fortschritte er- 
zielt. 


1.1. Entwurfsmethodik 


Der gesante Entwurfsprozeß von der Spezifikation des Pro- 

blems bis zur Wartung der fertigen Lösung wurde umfassend 

analysiert. Dabei wurden verschiedene Ursachen für die Ent- 

stehung fehlerhafter Software aufgedeckt und neue Entwurfs- 

methoden entwickelt /13/. Durch die Benutzung neuer Aus- 

drucksmittel oder die Einschränkung ‘der Möglichkeiten des 

Programmierers können viele Fehlerquellen vermieden und die 

Zuverlässigkeit der entstehenden Softwareprodukte, erhöht 

werden. Dazu zählen: 

- strukturierte Programmierung 

- modulare Programmierung 

- schrittweise Verfeinerung (Top-down-Entwurf) 

- grafische. Hilfsmittel für den Entwurf (z.B. Struktogranmne, 
HIPO) 
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- datenorientierter Entwurf (Jacksonmethode) 

- sichere Programmierung 

In Abhängigkeit vom Anwendungsgebiet kommen meist mehrere 
Methoden kombiniert zur Anwendung. Besonders gute Ergebnisse 
bei der Zuverlässigkeit der entstehenden Software und der 
Reduktion der Entwicklungekosten wurden dort erreicht, wo 
statt einer streng reglementierten Anwendung der Methoden 
eine schöpferische Übertragung durch den Programmierer auf 
die konkrete Aufgabenstellung gelang /5/. 


1.2, Programmiersprachen 


Im Zusammenhang mit den Erkenntnissen der Programmiermethodik 
entstanden verschiedenen Varianten vorhandener_Programnier- 
sprachen (z.B. strukturierte Sprachversionen für FORTRAN und 
PL/1), eingeschränkte Sprachvarianten höherer Programnier- 
sprachen für Klein- und Mikrorechner sowie neue Programmier- 
sprachen für die universelle und fachgebietsorientierte An= 
wendung, die ausgehend von den Ergebnissen unter 1.1 'ontwik- 
kelt wurden (z.B. PASCAL). Damit können die meisten Probleme 
des "Programming in the small" /6/ gut behandelt werden. 


Für die Lösung komplexer Aufgabenstellungen "Programming in 
the large” sind vor allem Hilfsmittel zur rationellen Auf- 
gabenzerlegung in Teilbausteine einschließlich exakter 
Schnittstellenbeschreibungen und -kontrollen erforderlich. In 
Form von Paketen-und Moduln findet man diese Ausdrucksmittel 
in modernen Programmiersprachen wie ADA /8,9/, MODULA 2 /2A/_ 
und anderen . Zusammen mit den Möglichkeitender separaten 
Obersetzung und der Anwendung des Prinzips der abstrakten 
Datentypen (Zusammenfassung von Daten und Operationen ‚damit 
in geschützten Kapseln mit exakten Schnittstellen) bei der 
Programmierung ergeben sich vielfältige neue Möglichkeiten 
/2,10/. Wie bei jeder neuen Methode und jedem Hilfsmittel 
bedarf es dazu aber entsprechender Vorkenntnisse und Erfah- 
rungen der Programmierer im Umgang danit. 


Parallel dazu entstanden neue Ausdrüucksmittel zur fehlertol- 
leranten Programmierung (Z.B. Assertions, Exceptions), die 
sowohl während des Tests als auch beim späteren Einsatz der 


233 


Software eine größere Zuverlässigkeit und Stabilität auch in 
abnormalen Fällen gewährleistet. In zunehmendem Maße werden 
‚auch informale und formale Spezifikationsmethaden bei der Auf- 
‚gabenformulierung, dem Entwurf, dem Test und der abschließen- 
den Dokumentation von Software angewendet. Sie ermöglichen 
eine exaktere Dokumentation, eine bessere Verständlichkeit 

und Modifizierbarkeit bis hin zu ersten gelungenen rechner- 
gestützten Beweisen der Korrektheit von Software in speziellen 
Anwendungsgebieten, Besonders mit dem Vordringen der Mikro- 
elektronik in neue Gebiete der Volkswirtschaft entstehen höhs- 
re Anforderungen bezüglich der Korrektheit und Anpaßbarkeit 
der dafür notwendigen Software. 


1.3. Programmierumgebunggn 


Mit dem ständig steigenden Einsatz. insbesondere von Klein- 
und Mikrorechnern in neuen Anwendungsgebieten und dem damit 
verbundenen starken Bedarf an spezieller Software ergab sich 
die Notwendigkeit der Verbesserung der rechentechnischen Un- 
terstützung der Softwareproduktion /1/f. Die in den vorhandenen 
Betriebssystemen enthaltenen Komponenten (Bibliotheken für 
Quelltexte und Programme, Editoren, Compiler, Linker, Test- 
Unterstützungen und Dump-Ausgaben) sowie deren fast ausschließ- 
liche Nutzungsmöglichkeit im Stapelbetrieb entsprachen nicht 
mehr den Wünschen der Nutzer. Erste Fortschritte wurden er- 
reicht durch eine zusätzliche Dialognutzung vorhandener Pro- 
gramme(z.B. TSO) und durch die Entwicklung von Software mit 
Hilfe von Crossystemen auf leistungsfähigeren Rechnern. Wei- 
tere Serviceprogramme und vor allem der Einsatz von Dialog- 
editoren und -compilern ermöglichem dem Nutzer eine echte 

und flexible Dialogarbeit. Es entstanden umfangreiche Ana- 
lyse-, Protokoll- und Testunterstützungen für verschiedene 
Programmiersprachen, bei denen während des Tests interpretie- 
rend gearbeitet wird und für den endgültigen Einsatz eine 
optimierende Codeerzeugung zur Verfügung steht. Das Prinzip 
der sequentiellen und untergliederten Dateien erfuhr eine 
Erweiterung durch nutzerspezifische Filesystene mit einfachem 
Zugriff und entwurfsgerechter Datenverwaltung. j 
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Eine vollständige und einheitliche Unterstützung des gesamten 
Entwurfsprozesses durch ein Programmiersystem von den ersten 
Grobvorstellungen über Entwurf, Codierung und Test bis zur 
‚Wartung der: fertigen Softwareprodukte ist das Wunschziel vio- 
ler Anwender /12/. Solche Programmiersysteme erlauben aber 
meist nur die Verwendung einer. Programmiersprache wie z.B» 
das’ CoL2-Labor /11/. 


In vielen Fällen läßt sich die gestellte "Aufgabe Statt durch 
'euprogrammierung rationeller durch Verwendung, Kopplung oder 
Anpassung vorhandener Programne lösen. Dies scheitert aber 
noch zu oft an fehlender Information oder unzureichender Doku- 
mentetion der vorhandenen Software. Abhilfe kann erst eine 
teilautomatisierte Sammlung, Verwaltung und Bereitstellung 
von Softwarelösungen in Programm-, Modell- oder Methodenbank- 
systemen schaffen, die die Nutzer im Dialog bei der Suche und 
Zusammenstellung der benötigten Teile. unterstützen. 

\ 


2. Anforderungen des Nutzers an ein Programmiersystem 


Die heute noch weit verbreiteten Bedingungen bei der Herstel- 
lung von Software entsprechen in den meisten Fällen nicht den 
Wünschen der Nutzer. Die vorhandenen Betriebssysteme mit ihren 
Teilprogramnen und Datenverwaltungsmethoden erzwingen eine 
Anpassung ‘der Denk- und Arbeitsweise der Nutzer an die vorhan- 
denen Hilfsmittel, Kommandosprachen und Datenstrukturen mit 
dem Ziel einer möglichst effektiven Auslastung der vorhande- 
nen Ressourcen an Speicherplatz und Rechenzeit, Dies ist un- 
ter anderem eine der Ursachen für die nicht ausreichende 
Qualität der entstehenden Software. Mit dem ständig steigen- 
den Ausrüstungsgrad an moderner leistungsfähiger Rechentech- 
nik-ist aber der Zeitpunkt gekommen eine Inversion des Ver- 
hältnisses Nutzer - Rechner durchzusetzen. Ausgangspunkt müs- 
sen die Nutzerwünsche und' ein entsprechender Komfort für 
deren Realisierung sein. Dazu’ gehören vor allem rationelle 
Dialogarbeit, leicht erlernbare Konsandosprachen, Unterstüt- 
zung problemorientierter Lösungen sowie progränniersprach- 
liche Hilfen bei Entwurf, Implementation und Test. Die inter- 
nationale Entwicklung /12,13/ geht in diese Richtung und 
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weist als Ergebnis eine schnellere und kostengünstigere Her- 
stellung von Softwäre bei deutlicher Verbesserung ihrer Zuver- 
lässigkeit nach., Moderne Programmiersysteme stellen dem Nut- 
zer Hilfsmittel bereit für die Lösung der bei der Softwarepro- 
duktion entstehenden Teilaufgaben. Die Wirksamkeit dieser ” 
Hilfsmittel ist um so größer, je besser sie untereinander ab- 
gestimmt sind und den Nutzer von seinen Routineaufgaben ent- 
lasten /1,4/. Eine sahr wichtige Rolle spielt dabei die Orga- 
nisation der Datenbasis und ihre Benutzungsmöglichkeiten, 


2.1, Entwurfsgerechte Verwaltung, Speicherung und Adressio- 
rung der Daten 


Die in den meisten Betriebssystemen übliche Datenverwaltung 
entsprechend den physischen Eigenschaften der Geräte und Da- 
tenträger (sequentiell, Direktzugriff, Bibliotheken) erfordert 
vom Nutzer einen größeren zusätzlichen Aufwand, denn sie ent- 
spricht nicht den Einheiten und Begriffen, in denen der Nutzer 
beim Programnentwurf und -test denkt und arbeitet. Der Nutzer 
verwendet Namen und logische Einheiten von Daten- und Programn- 
stücken, die sich entweder aus dem zu lösenden Problem oder 
aus den Begriffen der benutzten Programmiersprache ableiten 
lassen (z.B. Felder, Listen, Algorithmen, Prozeduren). Er: 
wird aber bei der heute noch weit verbreiteten Art der Daten- 
verwaltung gezwungen, zusätzlich mit Begriffen wie Bibliothek, 
Bestandsname und dessen Inhalt, Zeilenstruktur, physischer 
Satz und ähnlichen Einheiten zu operieren und seine Programme 
und Daten diesen unterzuordnen. Damit. ergeben ‚sich, , zusätz- 
liche Schwierigkeiten, die häufig zu Fehlern und Verzögerungen 
führen. Die in den Nüutzerprogrammen vorhandene natürliche 
Hierarchie und Namensgebung (s. Abbildung 1) geht dabei weit- 
gehend verloren, da es dazu kein Äquivalent in der Datenver- 
waltung gibt. Deshalb muß eine entwurfgerechte Datenverwaltung 
folgende Bedingungen erfüllen: 
- Begriffe und Einheiten, in denen der Nutzer denkt und ar- 
beitet, bestimmen die Struktur der verwalteten Daten 
- Namen, die in Programmen und Daten vorkommen, werden zur 
Adressierung verwendet. 
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- die vorhandene natürliche Hierarchie wird bei der Speiche- 
rung und Adressierung benutzt 

- Zugriffsrechte zu den Datenmengen müssen nutzerabhängig 

gestaltet werden 

elementare Datenmengen sollen einen überschaubaren Umfang 

haben, damit sie auch im Dialog -bearbeitet werden können. 


m 


Level Quelltext 


1 PROGRAM TRANSFORM( INPUT, OUTPUT ); 
2 PROCEDURE INP( ): 
5 
2 S END; (z INPx) 
2 PROCEDURE CHECK( .e. ); 
3 PROCEDURE ERROR( ): 
: 
3 END; (# ERROR %) 
3 PROCEDURE SEARCH ( }: 
4 PROCEDURE APPLY ( ): 
® 
® 
4 „END; (# APPLY %*) 
® 
® 
3 END; (% SEARCH x) 
3 PROCEDURE IGNORE( )i 
: 
3 „END: (X IGNORE %) 
2 END; (x. CHECK X) 


1: END. (% TRANSFORM %) 


L TRANSFORM 


2 IN — 
a >| SEARCH >| IGNORE 
4 APPLY 


Abbildung 1: Natürliche Einheiten und Hierarchie in einem 
| Nutzerprogrann 
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Aus den obigen Bedingungen folgt, daß ee notwendig ist, die 
Datenverwaltung mit Hilfe von Strukturbäumen zu organisieren, 
deren Aufbau sich unmittelbar aus dem Daten ableiten läßt und 
deren Feinheitsgrad und Knoteninhalte der Nutzer selbständig 
bestimmen kann. Alle Veränderungen, die während des Software- 
entwurfs vorgenommen werden, lassen eich mit Hilfe von Opera- 
tionen an diesen Strukturbäumen durchführen /3/. 


2.2. Unterstützung verschiedener Arbeitsweisen der Nutzer 


Leistungsfähige Programmiersysteme zwingen den Nutzer nicht 
zu einer bestimmten Arbeitsweise, z.B. strenger Top-down- 
Entwurf, sondern unterstützen verschiedene Vorgehensneisen, 
informieren den Nutzer über Struktur und Inhalt der gespei- 
cherten Daten und beraten ihn über mögliche weitere Arbeits- 
schritte (Fehlerkorrektur, Neuübersetzung, Schnittstellen- 
prüfung). ‘Sie ermöglichen sowohl den Entwurf neuer Progran- 
me nach top-donn-, botton-up-, funktionsorientierten, da- 
tenorientierten oder gemischten Strategien als auch die Lö- 
sung von Aufgaben durch Kombination vorhandener Routinen 

in Form einer Programm- oder Methodenbank /12/. 


Wesentliche, von der verwendeten Nutzerprogrammiersprache 

unabhängige, Teile eines Programmiersystems müßten sein: 

- leistungsfähige und einfach handhabbare Kommandosprache 
zur Gestaltung eines rationellen Nutzerdialogs 

- Informationen über Aufbau und Inhalt der in den Struktur- 
bäumen abgespeicherten Daten 

- Operationen zur Bewegüng in den Strukturbäumen durch re- 
lative oder absolute Angabe des Ziels verbunden mit einer 
Aktualisierung der erreichbaren Teile nach dem Focusprin- 
zip 

- Veränderungen der Strukturbäume durch Hinzufügen, Strei- 
chen oder Umhängen von Knoten mittels eines Baumeditors 

- Veränderungen elementarer Datenknoten der Strukturbäume 
mittels eines Texteditors 

- einfacher Datenaustausch mit der Betriebssystemumgebung 


Diese Aufzählung zeigt, daß eine große Zahl der Teilaufga- 
ben eines Programmiersystems unabhängig von der konkreten 
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Programniersprache der Nutzer gehalten werden kann. Sie sind 
gleichermaßen einsetzbar für Sprachen wie Assembler, Fortran, 
PASCAL oder MODULA 2 aber auch in einem Textsystem für die 
Herstellung von Dokumentationen. Für jeden konkreten Anwen- 
dungsfall ist lediglich die Bedeutung der Namen und Knoten- 
inhalte verschieden, nicht aber die Arbeit.-nit den Struktu- 
ren. Insbesondere in den ersten kreativen Etappen des Soft- 
waresentwurfs arbeitet der Nutzer mit verbalen oder formalen 
Spezifikation der Aufgabe und des Lösungsweges sowie längere 
Zeit mit unvollständigen meist. syntaktisch fehlerhaften Pro- 
gramnen. Gerade dabei,kann der Dialog in Form von Abspeiche- 
rung, Strukturinformation und Dokumentation wesentlich hel- 
fen, da dem Nuizer je nach Wunsch einen Überblick über das 
Gesamtproblen oder die Konzentration auf eine Teilaufgabe 
ermöglicht wird. Die im folgenden Abschnitt aufgeführten 
Teilaufgaben eind beliebig ab- oder aufrüstbar und bestim- 
men in Abhängigkeit vom Anwendungszwock den Komfort eines 
Programmlersystens. 


2.3. Sprachabhängige Teilaufgaben 


Zur besseren Unterstützung der Arbeit mit einer konkreten 
Programmiersprache insbesondere bei der Beseitigung syntak- 
tischer und semantischer Fehler sind folgende Bestandteile 
in einem Programmiersystem sinnvoll: ) 

- Analyseprogramme zur Bestimmung der Grobetruktur und Hie- 
rarchie einer sequentiellen Datenmenge als Hilfsmittel zur 
Aufspaltung eines Knotens verbunden mit einer vertikalen 
Verlängerung des Strukturbaumes entsprechen den Wünschen 
der Nutzer 

- Aufbereitungsprogramme für die Verwendung der Daten eines 
Teilbaumes zu Dokumentations-, Compilations- oder Test- 
zwiecken (Schrumpfen eines Teilbaumes) 

- entwurfsunterstützende Syntaxanalyse, die kontextfrei 
und mit vom Nutzer wählbarer Schärfe arbeiten kann 

- syntaxgesteuerte Editierung von elementaren Datenknoten 
im Dialog mit dem Nutzer 

- lokale und globale Kontextkontrollen 
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- Kontrolle der Schnittstellen zwischen Moduln und deren Aus- 
gabe an den Nutzer in übersichtlicher Form 

-- Testvorbereitung und Testhilfen 

- Übersetzung, Interpretation bzw. Abarbeitung von selb- 
ständigen Einheiten 


‘Mit ihrer weiteren theoretischen Durchdringung und überfüh- 
rung zur praktischen Nutzbarkeit werden Hilfsmittel aus fol- 
genden Gebieten zu wertvollen Bestandteilen von Programmier- 
systemens 


- Messungen des Programmverhaltens und deren automatisierte 
Auswertung (Tuning) 

=: Analyse der Programne zur Bestimmung oder Abschätzung zu 
erwartender Eigenschaften 

- Ableitung von Simulationsmodellen zur Erprobung des mög- 
lichen Programamverhaltens 

= Anwendung formaler Spezifikationsmethoden zur exakten Do- 
kumentation und für formale Beweismethoden 


Die Zusammenstellung dieser Möglichkeiten zur rechentechni-* 
schen Unterstützung der Softwareproduktion zeigt das aus 
heutiger Sicht Realisierbare. Viele bekannte Progranmnier- 
‚systeme /ı2/ enthalten nur einen Teil davon und sind auf 
einen konkreten Anwenderkreis zugeschnitten. Die Masse der 
verfügbaren Programmierhilfsmittel entspricht aber nicht ein- 
mal den hier aufgestellten Mindestanforderungen einer ent- 
wurfsgerechten Datenverwaltung. Es erfordert noch große An- 
strengungen, die Mehrzahl der bekannten Methoden und Hilfs- 
mittel einer großen Zahl von Nutzern verfügbar zu machen, 


3. Zielstellungen unseres Progranmmisrlabors 


Ein wichtiger, Schritt auf dem Weg zu einer umfassenden re- 
‘chentechnischen Unterstützung der Softwareproduktion ist die 
Sammlung eigener Erfahrungen bei der Entwicklung und Nutzung 
von Programmiersystemen unter Einbeziehung der Prinzipien | 
und Ergebnisse bereits existierender Systeme. Die daraus re- 
sultierenden Erkenntnisse können einerseits zu verallgenmei- 
nerten Merkmalen und Richtlinien_entwickelt und andererseits 
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bezüglich ihrer Realisierbarkeit, Effektivität und Nützlich- 
keit unter konkreten Einsatzbedingungen (Hardware, Software; 
Annenderspektrum) überprüft werden. Dabei kann auf langjäh- 
rige Erfahrungen bei der Entwicklung von Programmen in ver- 
schiedenen Betriebssystemen DOS, 0S, MS mit unterschiedli- 
chem Komfort aufgebaut werden. Gleichzeitig ist das Rrogram- 
mierlabor ein wirksames Hilfsmittel für: Entwurf, Codierung, 
Test und Analyse der Programme zur Lösung von Aufgaben an. 
unserem Bereich (Modellbetriebssysteme „ Simulation, Ausbil- 
dungsaufgaben). Das Anwendungsspektrum erstreckt sich dabei 
von kleinen und mittleren Programmieraufgaben über die 
Nutzung als Programm- oder Methodenbank bis hin zur Lösung 
komplexer Aufgaben. Es erleichtert die Arbeit des Nutzers 
durch Obernahme von Arbeitsanteilen (Speicherung, Verwaltung, 
Analyse), Unterstützung einer rationellen Arbeitsweise mit 
weniger Fehlern und Information über aktuelle Zustände und 
mögliche Weiterarbeit’ im Dialog. In der.ersten Variante 
werden vorrangig die sprachunabhängigen Teilaufgaben und 
einige auf PASCAL zugeschnittene sprachabhängige Teile rea- 
lisiert. 


3.1. Anwendung des Modulprinzips und der abstrakten Daten- 


typen 


Für die Entwicklung komplexer Programmsysteme bieten moderne 
Programmiersprachen in Form von Moduln in MODULA 2 oder Pa- 
keten in ADA sehr leistungsfähige Ausdrucksmittel /9,10,14/. 
Sie gestatten eine Zerlegung größerer Aufgaben in relativ 
selbständige Teilaufgaben (Bausteine) einschließlich einer 
exakten Schnittstellenspezifikation, die statisch überprüf- 
bar ist und eine größere Sicherheit der entstehenden Softwa- 
re gewährleistet. Damit ist auch. das Prinzip der abstrakten 
Datentypen im vollen Umfang realisierbar, was bei’ richtiger 
Anwendung zu einer deutlichen Reduktion der Komplexität der 
Probleme sorie besserer Verständlichkeit und Modifizierbar- 
keit der Programme führt /2,7/. 


Bei Entwurf, Implementation und Dokumentation des Progran- 
mierlabors wird das Prinzip der Strukturierung mit 'Moduln 
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im Sinne von MODULA 2 (nicht zu verwechseln mit dem weitver- 
breiteten und sehr unterschiedlich benutzten Begriff der mo- 
dularen Programmierung) angewendet und erprobt. Unter den 
Bedingungen der Arbeit in kleinen Kollektiven zusammen mit 
Studenten ist dies ein wesentlicher Faktor zur Gewährleistung 
der Zuverlässigkeit der entstehenden Software. Die Realisie- 
rung des Programmierlabors erfolgt aus Gründen der besseren 
Portabilität und Modifizierbarkeit in einer höheren Pro- 
grammiersprache. Einige wenige, für die Kopplung mit dem 
realen Betriebssystem zuständige Teile sind mit Hilfe der 
Assemblersprache zu realisieren und werden als externe Routi- 
nen äufgerufen. Da keine Compiler für ADA bzw. MODULA 2 auf 
den vorhandenen Rechenanlagen zur Verfügung stehen, erfolgt 
die Realisierung mit. Hilfe einer erweiterten Sprachversion 
M=PASCAL von PASCAL um wesentliche Teile des Modulkonzeptes 
aus 'MODULA 2. Ein Compiler und ein Precompiler (M-PASCAL 
PASCAL) sind als wesentliche Implementationshilfsmittel vor- 
handen. Eine separate Obersetzung von Modulen konnte nicht 
realisiert werden, da dazu-ein wesentlicher Eingriff in die 
Codegenerierung und in das Laufzeitsystem erforderlich wäre. 
Trotzdea ergeben sich. durch die Strukturierung mit Moduln 
und die Verwendung externer Routinen .bedeutende Vorteile 
gegenüber eifier Implementation mit PASCAL. 


3.2. Schichtenmodell des Programaierlabors 

Dem Nutzer stehen in der ersten Ausbaustufe das Programmier- 
labors als Programniersprachen PASCAL und M-PASCAL zur Ver- 
fügung. Eine Erweiterung auf andere Programmiersprachen ist 
aber wegen der allgsmeineren Orientierung des Gesamtsystens 
jederzeit möglich. Dazu sind einige der unter 2.3. angegebe- 
nen sprachabhängigen Teile entsprechend zu erweitern. Die 
Abbildung 2 zeigt ein Schichtennodell des Programmierlabors, 
Die Schnittstellenschicht 3 zum Wirtsbetriebssystem ein- 
schließlich der dazu notwendigen Assemblerroutinen kann da- 
bei einfach und sicher gestaltet werden, wenn sie als ab- 
strakter Datentyp mit exakter Spezifikation gestaltet wird, 
deren Operation auf einem relativ niedrigen Niveau liegen 
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und deren Daten nur über den Aufruf dieser Operatianen mit 
einfacher Parametergestaltung erreichbar sind. Alle anderen 
Teile können mit Hilfe von M-PASCAL oder PASCAL entnorfen und 
inplementiert werden. 


, 


6 Istruktur- Texteditor Testun- 
information] |. allgemeine terstürzung 


und Se 5 
 |Baumeditor spezielle ']Analyee, 
Teilaufgaben Messungen 
Datenverwaltung der 


- . Strukturbäume steuerung 


Datenbasis Terminal- 


steuerung 


Schnittstellennodul zum vorhan- 
denen Wirtsbetriebssysten. 


‚Betriebssysten 
Programme 


Hardware 


Abbildung 2: Schichtenmodell des Programnierlabors 


Die Organisation einer eigenen Datenbasis (Schicht 4) unab- 
hängig von der im :Wirtsbetriebssystem vorhandenen Datenorga- 
nisation ergibt sich aus der Notwendigkeit eines leistungs- 
fähigen nutzerorientierten Datenschutzes und den Möglichkeiten 
‘der Portabilität des Systems. Entsprechend der Leistungsfä- 
higkeit der auf dem Wirtssystem vorhandenen Datenverwaltung 
kann der Unfang der Schichten 3 und 4 variiert werden. Die 
Probleme der nutzergerechten Datenverwaltung und der Dialog- 
führung der Schicht 5 bestimmen wesentlich das Verhältnis 
Nutzer - Programmiersysten. Der erneiterbare Unfang dor 
Schicht 6 beeinflußt die Einsatzwuöglichkeiten und den Konfort 
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des Programmierlabors. Neben einigen sprachunabhängigen Teilen 
(Strukturinformation, Editoren) enthält diese Schicht alle 
sprachabhängigen Teile. Die Realisierung vieler Komponenten 
erfolgt im Rehmen der Forschungsarbeiten von ‘Studenten und 
Aspiranten. 
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Horn, Christian 


Breitbandsprachen und Programmentwicklung 


esse Te —A6e EEE 


Most problems have either many answers 
or no answer. Only a few problems have 
a single answer. 

E.C.Berkeley!) 


1. Einleitung 


Am Anfang steht das Wort - bei der Programmentwicklung die 
meist verschwommene Beschreibung der Aufgabenstellung in 
einer Sprache, die sich eigentlich nur "eingefleischte" 
Programmierer und vielleicht Mathematiker trauen als natür- 
liche Sprache zu bezeichnen. Ein Programm durchläuft dann im 
Zuge seiner Entwicklung mehrere sprachliche Ebenen, über die 
erste präzise.Spezifikation, verschiedene Stufen der applika- 
tiven (funktionalen) und imperativen (prozeduralen) Programn- 
beschreibung, den übersetzungsfähigen Quelltext bis hin ''zum 
ausführbaren Ma&chinenkode. Jede dieser Sprachen hat eine 
eigenständige Bedeutung: Sie widerspiegeln die für die jewei- 
lige Entwicklungsphase des Programms relevanten Aspekte 
besonders deutlich.und sind daher unter dem Gesichtspunkt 
der primär kommunikativen Funktionen einer Sprache für diese 
Entwurfsetappen prädestiniert. Legt man ein Phasenmodell für 
die Softwareproduktion zugrunde /15, 22/, so entsprechen 
diese sprachlichen Ebenen in etwa den Abschlußdokumenten der 
einzelnen Phasen; auch die Programmdokumentation setzt sich 
aus Einzeldokumenten verschiedener dieser Sprachen zusammen: 

Die Verwendung mehrerer sprachlicher. Ebenen birgt jedoch 
Gefahren. Die Übergänge zwischen den einzelnen Sprachen 
schaffen zusätzliche Unsicherheiten im Entwurfsprozeß. Sie 
erfordern besonders große Sorgfalt,wenn es gilt, das Zusammen- 
spiel von Programmkomponenten zu realisieren, die jeweils 
unterschiedliche Entwicklungsstadien repräsentieren. 


1) zitiert nach /6/ 
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Breitbandsprachen verkörpern nun einen Kompromiß. Sie 
versuchen,den gesamten Bereich von der Problemspezifikation 
bis zum direkt Übersetzungsfähigen und genügend effektiven 
Quellprogramn in einer Sprache zu berdecken. Sie sind damit 
zwar auf jeder einzelnen sprachlichen Ebene den konventionel- 
len Ausdrucksmitteln (geringfügig?) unterlegen, bieten aber 
größere Sicherheit bei den Übergängen zwischen den einzelnen 
EFhasen und erlauben vor allem eine durchgängige Rechnerunter- 
stützung über alle Phasen des Programmentwurfs. Breitband- 
sprachen (engl. wide-spectrum languages) nlissen daher eine 
Vielzahl aufeinander abgestimmter Ausdrucksmittel umfassen: 
Für jede Klasse von Programmelementen (Datentypen, Ausdrücken 
und Anweisungen), die verschiedenen Entwicklungsstufen 
(deskriptiv, applikativ und imperativ) und die problem- 
abhängigen Abstraktionsebenen müssen sich geeignete Darstel- 
lungsformen finden. Die Sprache. muß aber zugleich übersicht- 
lich, erlernbar und praktisch handhabbar sein, 

Der vorliegende Beitrag will eine Einführung in die Struktur 
und den Gebrauch von Breitbandsprachen geben, wobei dem 
Kalkül der Programmtransformationen naturgemäß besonderes 
Gewicht zukommt. 


2. Zur Organisation der Programnentwicklung 


Der Programmentwurf gliedert sich zeitlich in eine Folge 

von Entwurfsschritten 
(Do; Ps Pos +++, Pu) 

wobei jeder Entwurfsschritt 55: pP —D Ppy,ı AIn'der streng 
lokalen Anwendung einiger weniger Entwurfsoperationen besteht. 
Der Programnmentwurf beginnt mit einer ersten Spezifikation 
der Aufgabenstellung (p,) und endet mit dem "fertigen", 
direkt übersetzungsfähigen Programm (p,) . Am Anfang steht 
jedoch nie eine vollständige Spezifikatän der Aufgabenstel- 
lung. Erst im Zuge der Programmentwicklung kommt es zu einer 
schrittweisen Annäherung der Spezifikation an die eigentliche 
Aufgabenstellung, wobei die Spezifikation dann bereits 
derartig über das Programm "verteilt" ist, daß es kaum noch 
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nöglich ist, von der Spezifikation des fertigen Programms zu 
sprechen. Weiterhin ist eine rein deskriptive Beschreibung 
realer Programme wenig nutzbringend weil unnötig kompliziert. 
Viele Prozesse und Eigenschaften sind in ihrer algorithmischen 
Darstellung leichter faßlich. 

Die Korrektheit des Programms Pn bezüglich der Anfangs- 
spezifikation Po ist in den meisten Fällen trivial erfüllt. 
Wir wollen daher die Korrektheit des Entwurfsprozesses ein- 
führen an definieren: 


Def. Bin Entwurfsprozess (po > Ps ++. Pn) heißt: korrekt, 
wenn für beliebige 1,j mit O<i<j<n das Programm pP; 
bezüglich Pr korrekt ist. Ein Entwurfsschritt 

8,3 Pı > Pıy heißt korrekt, wenn Pr bezüglich P4 
korrekt ist. 


Jedes vorangehende Entwurfsstadium eines Programms muß also in 
gewissem Sinne als "Spezifikation" eines nachfolgenden Ent=: 
wurfsstadiums angesehen werden. Es: ist notwendig,die Korrekt- 
heit, bisher als Relation zwischen rein deskriptiver und 
imperativer Darstellung eines Programms betrachtet, weitgehend 
zu verallgemeinern. Grundlage hierfür aind die Arbeiten zur 
Äquivalent und Einbettung von Programmen /7/. Durch Induktion 
sieht man sofort, daß ein Entwurfsprozess’ genau dann korrekt 
ist, wenn jeder der konstituenten Entwurfsschritte korrekt 
ist. Auf das Problem der Korrektheit von Entwurfsschritten 
kommen wir im nächsten Abschnitt zurück, 

Die einzelnen Entwurfsschritte sind von sehr unterschied- 
lichem Charakter: einige verkörpern fundamentale Entwurfsent- 
scheidungen, andere schöpfen einen durch nichtdeterministische 
bzw, rein deskriptive Konstruktionen gegebenen Spielraum aus. 
Die Mehrzahl der Entwurfsschritte besteht jedoch in der An- 
wendung wohlbekamter Entwurfsoperationen auf konkret vorge- 
gebene Teilstrukturen. In den meisten Fällen besteht die Aus- 
wahl nur zwischen wenigen alternativen Lösungsvarianten, 
jeder Programmierer hat sich aufgrund seiner Erfahrungen 
gewisse "Standardlösungen" zu eigen gemacht. Längst bekanntes 
wird in monotoner Weise ständig wiederholt. Trotzdem steckt 
die Rechnerunterstützung für diese Tätigkeiten noch in den 
Kinderschuhen /16/. t 
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Die gegenwärtige Technologie der Softwareproduktion wird 
durch drei wesentliche Elemente geprägt: die Entwurfsmethode, 
die sprachliche Basis und die verwendeten, technischen Hilfs- 
mittel (Werkzeuge). | 


Entwurfs- 
methoden 
> sprachliche 
>> Basis ' 
Programmier- 
werkzeuge 


Abb.1 Elemente der Softwaretechnologie 


Die verschiedenen Entwurfsmethoden lassen sich nach globalen 
und lokalen Merkmalen unterscheiden. Geht man von dem allgemein 
üblichen Baummodell für die Programnstruktur aus, so durchläuft 
jeder Knoten (jedes Programmelement) im Zuge der Programnm- 
entwicklung (möglicherweise in geraffter Form) die einzelnen 
Entwurfsetappen. Die Wechselwirkung zwischen Programmelementen 
beschränkt sich dabei in der Regel auf benachbarte Knoten 
(Lokal itätsprinzip). Globale Merkmale beschreiben die Reihen- 
folge, in der 'die einzelnen Knoten der Baumstruktur nachein- 
ander eine gewisse vorgegebene üntwicklungsstufe durchlaufen 
(vgl. Abb.2). Lokale Merkmale beschreiben die Folge der Gene- 
rationen eines einzelnen Programmelements von der ersten 
Spezifikation auf relativ hohem Abstraktionsniveau (Problem- 
ebene) bis hin zur Implementation der präzisierten Aufgaben- 
stellung auf vergleichsweise niedrigem (Maschinen-)Niveau. 

Zur Darstellung dieser Generationenfolge haben sich Entwurfs- 
diagramme (engl. refinement-realization-space /10/) bewährt. 
(vgl. Abb.3). 

Natürlich 'erlaubt diese Klassifikation der Entwurfsmethoden 
(vgl. Abb.4) nur eine, grobe Einteilung: dazwischen gibt es 
eine Vielzahl von Abstufungen. Praktisch eingesetzte Methoden 
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Abb.3 Lokale Organisation des Programmentwurfs 


stellen immer eine Verquickung der "abstrakten Methode" mit 
speziellen sprachlichen Mitteln und Werkzeugen dar. Glaubte 
man in der Anfangszeit des "Software-Engineering", durch eine 
geeignete, festgefügte Organisation der Programmentwicklung 
das Softwareproblem bewältigen zu können, so wissen wir heute, 


x Entwurfsstrategien 

- top-down 

- bottom-up 
a Entwurfsprinzipien 

- breadth-first 

- depth-first 

- most-difficult-first 
a Entwurfstechniken 

- refinement-first 

- realization-first 


Abb.4 Klassifikation der Entwurfsmethoden 
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daß eine Methode allein nur in engen Spezialfällen zum Erfolg 
führen kann. Die Zeit hitziger Diskussionen um einzelne 
Methoden ist im wesentlichen vorbei. Wir kennen annährend die 
Wirkbedingungen, unter denen die verschiedenen Methoden nutz- 
bringend angewandt werden können - auch wenn diese Erkennt- 
nisse noch nicht im notwendigen Maße praxiswirksam werden. 
Der Programmierer beginnt in der Wahl seiner Mittel freier 
zu werden - freier im dialektischen Sinne; er beginnt die 
zur Lösung der vorgegebenen Aufgabe geeignetsten Mittel und 
Methoden bewußt einzusetzen. Der Trend geht zu für die prak- 
tische Anwendung aufbereiteten Bündeln von Methoden, aufein- 
ander abgestimmten sprachlichen Mitteln und Softwarewerk- 
zeugen /15/. Doch steht dem häufig die Unverträglichkeit 
der verschiedenen sprachlichen Ausdrucksmittel entgegen. 
Breitbandsprachen verkörpern ein verallgemeinerndes, ein- 
heitliches aber erweiterbares Sprachkonzept, das’die Integra- 
tion verschiedener Entwurfsmethoden unterstützt/5,6/. Ea. kann 
sich nicht darum drehen, eine Universalsprache zu schaffen, 
die es erlaubt, alle Probleme mit einem Schlage zu lösen. 
Breitbandsprachen stellen zunächst ein Konzept dar - genau 
wie die. geläufigen modernen Programmiersprachen bei all ihren" 
Unterschieden dem Konzept der prozeduralen algorithmischen 
Sprache folgen. "Neue Sprachen setzen sich nicht im luftleeren 
Raum durch. Es wird daher ganz natürlich sowohl PASCAL- als 
auch ALGOL-, PL/1- oder Ada-ähnliche Breitbandsprachen geben. 
Ansätze hierzu sind die PASCAL- und ALGOL-Versionen von CIP-L 
/3-6, 24, 25/ und ABSTRACT-PASCAL/13,14,18/. ‘Für einige 
Anwendungsgebiete bieten sich auch fachsprachliche Erweite- 
zungen bzw. Versionen dieser universellen Breitbandsprachen 
en. Wenn dadurch erreicht würde, daß formale Spezifikationen 
für den. Fachwissenschaftler oder Ingenieur als natürliche 
Ausdrucksweise ihres Anliegens akzeptiert werden, dann 
hätten wir einen wesentlichen Schritt vorwärts getan. 


3. Rechnerunterstützung für den Programmentwurf 


7 - 
Im Laufe der Jahre hat sich eine relativ feste Dateiorga- 
nisationsform für die Programmentwicklung herausgebildet, die 

von der Mehrzahl der im Einsatz bzw. in der Entwicklung 
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befindlichen Programmiersysteme genutzt wird /13, 14, 17, 18, 
20, 24/. Das "Skelett" dieser Dateien bildet eine Baumstruk- 
tur, deren Knoten relativ selbständige Programmelemente 
darstellen. Jeder Knoten beinhaltet verschiedene Generationen 
und Versionen ein und desselben Programmelements. Die Ver- 
kettung der Knoten untereinander widerspiägelt die „Block- 
bzw. Modulstruktur des Gesamtprogramms, Die Adressierung 
erfolgt hierarchisch über die Namen der Programmelemente. Es 
gibt keine speziellen "Bestandsnamen". Eine Vereinfachung 
der Adressierüng unter Berücksichtigung der Sichtbarkeits- 
regeln für Bezeichner ist möglich, Für die einzelnen Knoten 


em P | Beispielprogremn 
module storage 
type address m ..; 
ver 8: 


proc put, get 
begin "initialisierung" end 
proc input, procesp, output Per 
begin "hauptprogramm” end. 


program Dateistruktur 
Fa: 
N ISIIrmn 
N SILITS an 
N "SI "IST 
. e i nn 
module proc roc proc 
storage ‚input process output 
1] 24 ! Be 


. ] 


. / „""Q_ Relation 


en < zer "ruft auf" 
| 
‘| addre a = 5 Parc 
address 8 put | get . hlerarchische 
Adressierung: 
P.storage „get 


Abb.5 Dateistruktur oder P,get 
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sind eine Vielzahl von Prädikaten (z.B, "ist syntaktisch 
fehlerfrei/fehlerhaft", int bereits Übersetzt" oder 
"ist erfolgreich verifiziert") und Relationen (z.B. "ruft 
auf", "benutzt", "ist unverträglich nit") defihiert, deren 
Verwaltung sich auf Standarddatenbankmechanismen stützt -/16,20/. 
Abb.5 zeigt die Dateistruktur für ein kleines Beispielprogremn. 

Beim Entwurf von Programmen werden immer. wieder die gleichen 
elementaren Operationen ausgeführt. Egal ob dazu ein syntax- 
oder zeichenorientierter, ein muster- oder adressengesteuerter 


Editor oder ein anderes leistungsfähiges Programmierwerkzeng 
benutzt wird, für den Programmierer bleibt ein großer Teil 


monotoner, mechanischer Arbeit, Moderne Programmiersysteme 
besitzen daher eine eigene (an die zugrundeliegende Progran- 
‚miersprache bzw. an das Basisbetriebssystem angeglichene) 
Steuersprache /17,24/, die eu gestattet immer wiederkehrende 
Folgen von Entwurfskommandos zu Entwurfs"prozeduren" zusam- 
menzufassen. Es wird ein Sortiment von Grundkommandos bereit- 
gestellt. Mittels bedingter, rekursiver und iterativer Kon- 
struktionen lassen sich über Prädikate und Relationen gesteu- 
ert komplexe Entwurfsabläufe vorprogrammieren. Man spricht 
hierbei bereits von "Metaprogrammierung" /11/. 

Die entscheidende Frage liegt nun darin, welche Grundkomman- 
dos für den Progremmentwurf zur Verfügung gestellt werden. 
Die "normalen" Updatefunktionen (Einfügen, Streichen oder 
Modifizieren von Zeichenketten oder Syntaxeinheiten) sind 
als Grundfunktionen in intelligenten Terminals realisiert 
und stehen damit ‚jederzeit zur Verfügung. Nach derartigen ' 
Änderungen ist jedoch stets die Konsistenz des modifizierten 
Programmelements mit seiner Umgebung zu Überprüfen. Da wir 
von vornherein an korrekten Entwurfsschritten interessiert 
sind, wäre es ratsam als Grundoperationen korrektheitserhal- 
tende Programmtransformationen aufzunehmen, Eine beliebige 
Verkettung solcher "Mikrotransformationen" bildet wiederum 
eine korrekte Programmtransformation, u.U. mehrere solcher 
Programmtransformationen bilden einen korrekten Entwurfs- 
schritt. Das erste Programmentwicklungssystem auf der Basis 
von Programmtransformationen stammt von Burstall und 
Darlington /8/. Inzwischen sind in der Literatur über ein 
halbes Dutzend derartiger Systeme belegt /4, 19/. 
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4. Programmtransformationen 


Alle Methoden für den (schrittweisen) Entwurf korrekter: 
Programme stützen sich auf verschiedene Formen semantischen 
Schließens. Werden jedoch mechanische Systeme zur Unterstützung 
des Programmentwurfs und zur Absicherung der Korrektheit der 
einzelnen Entwurfsschritte eingesetzt, so müssen diese seman- 
tischen Beziehungen syntaktisch charakterisiert werden. .Der 
Übergang von einer Generation eines Programmelements zur 
nächsten wird am einfachsten durch formale Transformations- 
regeln beschrieben, ähnlich den Schlußregeln der formalen 
Logik. : 

Allgemein gesprochen ist eine Programmtransformation R 
eine partielle Abbildung, die einem Programnstlick .S der 
Eingangssprache L, „sofern die Anwendbarkeitsbedingung B 
erfüllt ist,ein neues Programmstück T=R(S)- der Ausgangs- 
sprache D, * zuoränet. Die Vorteile des transformationellen 
Ansatzes, insbesondere die weitgehende Rechnerunterstützung, 
die sich aus der Möglichkeit beliebiger Verkettung von Trans- 
formationen ergibt, können in den meisten Fällen jedoch nur 
dann genutzt werden, wenn Eingangs- und Ausgangssprache 
zusammenfallen, wenn L,-L, . Zur Darstellung von Programn- 
transformationen gibt es prinzipiell zwei Möglichkeiten; 


(1) Eine Programmtransformation kann in Form eines Algo- 
rithmus gegeben werden, der die Abbildung R reali- 
siert, d.h. auf die Eingabe eines Programnstückes 5 
mit der Ausgabe des Programnstückes T=R(S) antwortet. 
Conpiler arbeiten z.B. nach diesen Schema. 


(1i) Eine Programntransformation kann aber auch als geord- 
neteg Paar von Programmschemata dargestellt werden, 
bestehend aus einem "Eingabemuster" 5 und einem 
"Ausgabemuster" T /19, 23/, die der Prämisse bzw. 
Conclusio einer Postschen Regel entsprechen, und ggf. 
einer Anwendbarkeitsbedingung B . Die Anwendung einer 
Programmtransformation auf ein 'gegebenes Programm ist 
dem Substitutionsschritt eines Postschen Systems 
vergleichbar. 
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„Abb.6 Schema für Transformationsregeln- 


Es gibt verschiedene Ansätze, die für den Programmentwuf 
zweckmäßigen Programmtransformationen in geeigneter Weise 
zu systematisieren. Dabei zeichnen sich zunächst zwei Ebenen 
ab: Basisregeln, die die kleinsten durch Transformationen 
lösbaren Aufgaben beschreiben, und sogenannte abgeleitete 
Regeln, die sich in wohl definierter Weise aus Basisregeln 
zusammensetzen. Als System von Basisregeln hat wahrschein- 
lich ein Regelsystem von Gentzen'schen Typ die größten. Aus- 
sichten: Ein solches Regelsystem enthält nicht nur für jeden 
logischen Funktor, sondern darüberhinaus für jede Operation, 
für jede Funktion und jede algorithmische Konstruktion eine 
Einführungs- und eine Eliminationsregel .. (vgl. Abb.7). Die 
bekannten FOLD- und UNFOLD-Regeln sind hier als Einfüh- 
rungs- bzw. Eliminationsregel für Funktionsaufrufe einzuordnen. 

Für jede der Transformationsregeln muß natürlich die Korrekt- 
heit bewiesen werden. Eine Programmtransformation heißt 
korrekt, wenn es eine semantische Einbettung von T in 5 
gibt, d.h. wenn zu jeder Interpretation von T eine schwach 
(d.h. in bezug auf das äußere Verhalten) äquivalente -Inter- 
pretation von S existiert. Für den Nachweis der Korrektheit 
einer Programmtransformation glbt es wiederum zwei grundsätz- 
liche Möglichkeiten. Zum einen kann man die obige Eigenschaft 
unter Bezugnahme auf die Semantik der Sprachen L, und I, 
direkt beweisen. Man kann aber auch. eine Anzahl von Basis- 
regeln als gegeben (Axiome) betrachten, und versuchen, neue 
Transformationen konstruktiv als Nacheinanderausführung dieser 
Basisregeln darzustellen. Dieser letztgenannte Weg führt auf 
die sogenannte "transformationelle Semantik" von Programmier- 
sprachen /21/. 
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5. Ein Beispiel 


{En = 1 nn .2 [1 = 2] 

Mit dem folgenden Beispiel-sollen die wesentlichen Elemente’ 
einer Breitbandsprache vorgestellt und in ihrem Gebrauch 
demonstriert werden. Wir stützen uns dabei auf die Sprache 
ABSTRACT-PASCAL/13,14/. ABSTRACT-PASCAL entstand ursprünglich 
als Erweiterung der Sprache PASCAL für Zwecke der automati- 
schen Programnverifikation. Sie umfaßte anfangs daher nur 
Ausdrucksmittel für die systematische Programmannotation /1,2/. 
Genaueres Studium der Entwurfsprozesse /18/ führte zu der 
Erkenntnis, daß die Ebene der applikativen (funktionalen) 
Programnierung als Bindeglied zwischen Spezifikation und 
"reinen" PASCAL-Programmen (als Vertretern für prozedurale 
Programmierweise) einfach notwendig ist. Bestärkt durch ent- 
sprechende internationale Entwicklungen, wurde ABSTRACT-PASCAL 
schrittweise von einer "Spezifikations- und Programmier- 
sprache" /13/ zu einer Breitbandsprache aufgerüstet. 

In diesem Abachnitt soll ein Programm zur Berechnung der 
ganzzahligen Wurzel einer nichtnegativen ganzen Zahl entwik- 
kelt werden. Wir folgen dabei dem Ansatz von Dijkstra /9/ 
und Gries /12/. Am Ende des Abschnitts werden die Ausdrucks- 
mittel der Sprache ABSTRACT-PASCAL in einer tabellarischen 
Übersicht zusammengefaßt. 

5.1. Spezifikation der Aufgabenstellung 


um m nee an am an um am am u Cm Cm CD ME ER AR CEO Un ER ED MED vun ar DE On ul ar TED DD GR A un up OR am 


Am Anfang steht die formale Spezifikation der Aufgabe: 


(. 1 ) function isgrt(ns integer/ n>a0): integer 
(2) abstract isgrt(n)®&n<(isgrt(n)+1)® end 


Bemerkungen: 
1. Win haben eg hier mit einer deskriptiven Funktionsverein- 


barung zu tun; die Funktion wird durch eine Aussage über die 
Funktion als Ganzes definiert. Allgemein sind deskriptive 
Funktionsvereinbarungen von der Gestalt 


function £(xı t/ h,)ı tt abstract H, end , 


wobei h, den Definitionsbereich der Funktion beschreibt, 
und HB, eine Aussage über die Funktion f darstellt, 
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Deskriptive Punktionsvereinbarungen sind notwendig um 
Aussagen Über Funktionen zu formulieren, die mehr als einen 
Funktionswert betreffen. & sei z.B. eine beliebige auf dem 
Intervall 0..100 monotone Funktion. Wir definieren dann: 


predicate monoton( function f(x: integer): integer; 
a, bs integer) 
= lall(m, n: integer/ asm«nsb): f(m)s£f(n) ; 
function g(i: integer): integer 
abstract monoton(g, O, 100) end 


2. Die formalen Parameter der Funktion gelten innerhalb der 
Funktionsvereinbarung als generalisierte Variablen, d.h. 

e \ 
Zeile (2) ist eine Kurzform für 


tall(n: integer/ n>0): isart(n)?& n< (isart(n)+1)® 


(lies: "für alle 'n'! vom Typ "integer!' mit 'n>20' gilt ..."). 
3. Aus Gründen der leichteren Lesbarkeit wird in diesem 
Abschnitt durchgehend von der Exponentenschreibweise gebrauch 
gemacht. 'Korrekt müßte es anstelle von x? stets sar(x) 
heißen. Ebenso werden wir für die ganzzahlige Division den 
Schrägstrich a/b anstelle von a div b verwenden. U 


Am Anfang des Programmentwurfs könnte ebenso eine applika- 
tive Funktionsvereinbarung stehen: 


( 1.) function isqrt(n: integer/ n>0): integer 
(2!) = the(is integer/ iten<(i+)®) 


Bemerkungen; 
1. Applikative Funktionsvereinbarungen haben die Form 


function f(x; t/ h): tt ='e, - 
wobei h, wiederum den Definitionsbereich der Funktion 
beschreibt, und e, ein Ausdruck vom Typ tt mit der freien 
Variable x (vom Typ #) ist, der für alle x mit h, 
definiert ist. Applikative Funktionsvereinbarungen ent- 
sprechen der Wertverlaufsdefinition für Funktionen im mathe- 
matischen Sinne, 

2. Funktionen müssen nicht notwendig determiniert sein. Der 
definierende Ausdruck e, kann sowohl deskriptive als auch 


applikative Ausdrucksmittel enthalten. In Zeile (2') haben 
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wir es mit einem solchen deskriptiven (abstrakten) Ausdruck’ 
zu tun. Man unterscheidet gewöhnlich drei Formen von 
abstrakten Ausdrücken: 


alllxı t/ h,) lies: "die Menge aller 'x! vom Typ 't'! 
mit der Eigenschaft 'h'" , 

otafx: t/ h,) liesı "ein (beliebiges) 'x' vom Typ 
'!tt mit Dza8 und 

the(x: t/ h,) lies: "dasjenige 'x! vom Typ 't'! mit 


der Eigenschaft nn 


Diese abstrakten Ausdrücke entsprechen dem Mengenkonstruktor 
"{z: h,}", dem Auswahloperator "," bzw. dem Kennzeichnungs- 
operator "L " im geläufigen mathematischen Sinne. 

3. Ein wichtiges Ausdrucksmittel zur Formulierung von Aussagen 
über Programmelemente sind Quantoren. Den Allquantor (lall) 
haben wir bereits benutzt. Man unterscheidet wiederum drei 
Arten von Quantoren: - 


tall(x: t/ h,): hh, lies: "für alle 'x' vom Typ 't' mit 
'h_" gilt die Bedingung 'hh'" , 

Ione(xt t/ h,) lies: "es gibt ein 'x'! vom Typ 't" mit 
der Eigenschaft nSen und 


Ithelx: t/ h,) lies: "es gibt genau ein 'x! vom Typ 
!tt'! mit der Eigenschaft Rz!N . 


Auch wenn es theoretisch möglich wäre, den Allquantor als 
alleinigen Quantor zuzulassen, und man sogar diesen auf Grund 
des Parameterkonzepts eliminieren könnte, hat sich diese Drei- 
einigkeit speziell in der Programmierung bewährt. Alles andere 
bedeutet nichts weiter als erhöhten Schreibaufwand und so 
etwas wie "logischen Harakiri". Die Analogie der Quantoren 

zu den abstrakten Ausdrücken und zu den Parameterabschnitten 
der Funktions- und Prozedurvereinbarungen ist natürlich beab- 
sichtigt. 


Mit der zweiten Fassung der Spezifikation haben wir schon 
einen gewaltigen Fortschritt gemacht: Wir wissen nun, daß es 
genau einen Wert mit der geforderten Eigenschaft gibt, und 
kennen -eine obere und ’eine untere Schranke fiir den Fuhktionswert, 
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Aus den bisher vorliegenden Informationen können wir die 
erste Fassung des Algorithmus herleiten. Die Grundidee ist 
simpel. In Anfängervorlesungen zur Analysis wird sie oft als 
Löwenfangmethode bezeichnet: "das Intervall zwischen oberer 
und unterer Schranke wird solange halbiert bis man den gesuch- 
ten Funktionswert hinreichend genau bestimmt hat. Da wir nun 
mit ganzen Zahlen rechnen, erhalten wir als Genauigkeits- 
schranke, die den Abbruch des Verfahrens garantiert 1. Dafür 
müssen wir aber garantieren, daß ein Halbieren der Intervall- 
länge stets möglich ist. Am einfachsten wählt man hierzu die 
Anfangswerte für die obere und untere Intervallgrenze so, 
daß die Intervallänge gerade eine Zweierpotenz ist. Dieses 
Verfahren der Intervallschachtelung ist so allgemein, daß es 
sich lohnen würde, die entsprechenden Funktionen in einer 
Bibliothek von Standardmethoden bereitzustellen: 


( 1) predicate power_of_2(x: integer) 

(2) = toneli: integer/ wei=x); 

( 3) £unction inversion( function f(x: intsger): integer; 
( 4) Iwb, upb: integer 

(5) / monoton(f, Iwb, upb) & £(1lmb)<0 & 
(6) f(upb)>0 '& power_of_2(upb-Iwb) 
(N ): integer 

(8) = if upb-1wb=1 {Intervallänge gleich 1} 

( 9) "then 1wb funtere Grenze 3 

(10) else if f(xxx)<O 

(11) then inversion(f, xxx, upb) 

(12) else inversion(f, lwb, xxx) 

(13) fi 

(14) fi 

(15) where 

(16) function xxx: integer =(l1wb+upb)/2 


(17) end finversion? 


Bemerkungen: 

1. Die Funktion inversion berechnet die "ganzzahlige Null- 
stelle" der monoton wachsenden Funktion f im Intervall 
lAwb..upb . 
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2. Die Funkticn inversion ist durch einen bedingten Ausdruck 
definiert. Man unterscheidet zwei Formen bedingter Ausdrücke: 
den deterministischen bedingten Ausdruck (in Anlehnung an 
Algol): 


äf b then e, else e, fi 
und den nichtdeterministischen bedingten Ausdruck (vgl. /9/): 


2b, —eH ab, mo, f 


wobei die b, jeweils Boolesche Ausdrücke und die e, Ausdrücke 
von einem gemeinsamen Typ t „ dem Resultattyp des bedingten 
Ausdrucks sein müssen. Bedingte Ausdrücke, sind ein unent- 
behrliches Hilfsmittel zur Definition rekursiver Funktionen. 

3. Die where-Klausel am Ende einer Funktions- oder Prozedur- 
vereinbarung umfaßt Vereinbarungen, die lokal zu der jeweiligen 
Funktion bzw. Prozedur sein sollen. Sie stellt gewissermaßen 
einen "Nachtrag" zum Deklarationsteil einer Vereinbarung dar. 
In vielen Fällen erhöht sich durch ein solches "Nachstellen" 
einiger lokaler Objekte die Lesbarkeit, indem nämlich die 
wesentliche Teile der Vereinbarung (Kopf und Körper) nicht 
durch unwesentliche Festlegungen getrennt werden. 

4. Prädikate werden in ABSTRACT-PASCAL wie Boolesche Funktionen 
behandelt, mit dem Unterschied,daß Prädikate in der Regel 


(d.h. außer zu Testzwecken) nicht implementiert werden. Genau 
wie für Funktionen gibt es deskriptive und applikative Prädi- 


kat vereinbarungen. EI 


Unter Benutzung der Funktion inversion erhalten wir eine 
erste algorithmische Darstellung für. isqart 


( 1) function isqrt(n: integer/ n>0): integer 

( 2) = inversion(g, 0, obere_schranke) 

( 3) where s 

( 4) function g(x: integer): integer = xe-n 3 
(5) funcetjon obere_schranke: integer 

(6) = 2szone(i: integer/ (2zzi1)”>n) 

CT) end [isartj 


: “z 
Durch Teilberechnung (Einsetzen und Auflösen von g und 
xxx ) und anschließendes Zusammenfassen zu einer neuen 
(Hilfs-)funktion invert_sqr entsteht daraus 
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( 1) function isgrt(n: integer/ n»a0): integer 

( 2) = invert_sqr(0, obere_schranke) 

( 3) where 

(.4) Zunetion invert_sqr( 1wb, upbs integer ® 
( 5) / Iwb°-n g0.& upb®-n >0 & 
(6) power_of_2(upb-1wb) 
(D ): integer' 

(-8) = i£ upb-1wb=1 

(9) then :lwb 

(10) else i£ ((Iwbiupp)/2)°-n «O0 

(11) then invert_sqr( (l1wb+upb)/2, upb) 
(12) else invert_sqr( Iwb, (1wb+upb)/2) 
(13) fi 

(14) 23; 

(15)  S£unction obere_schranke: integer 

(16) = 2zsone(i: integer/ 4z=21>n) 


(17) end fisgrtj 


Durch Anwendung des allgemein gültigen Transformations- 
schemas WIp (while-introduction for partially defined func- 
tions) entsteht die erste prozedurale Version der Funktion 
isqrt (vgl. Abb.7) 


function F(x: T/ D(x)): TT 
= if B(x) 
then H(x) 
else -F(G(x)) 
fi 


function D(x: T):Boolean; 


function B(x: T/D(x)): 
Boolean; 


function G(x: T/D(x)): T; 
- function H(x: T/D(x)): TT; 


funetion F(x: T/ D(x)): TT 
ver xx: T; 
begin xxX:=X; 
while not- B(xx) do 
begin assert(D(xx)); 


X:=G(xx) 
end; 
F:=H(xx) 
end NS 


Abb.7 Transformationsschema WIp 
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5.3s_Der Algorithmus_auf prozeduralem Niveau 
(ij funetion isart(nı integer/ n>0): integer: 
(2) var iwd, upbs Integer; 
(3) begin (iwb,upb) 4= (0, öbere_schranke); 


(4) whtie upbelwbft do _ | 

(5) tepin assert( Iwbeen<upp? & poöwer_of_2fupb-iwb) ); 
(6) if ((Iwb+upb)/2)°<u 

%» then (1wb,upb) ı= ((1wb+upb)/2, upb) 
(8) eise (iwb,upb) s= (Imb, (1wb+upb)/2) 
( 9) endz : 

(16) isgrt s=1wb 

(11) end 

(12) ytere 

(13) funstion obere schrankes Integer 

(14) u 3zsons(i: integer/ 4zei>n) 

(155 end [isgrt 


jemerküngens, 
1; Das auffälligste an dieser Implementation dürfte die 
systematische Verwendung simultaner Wertzuweisimgen sein. 
Besonders Dijkstra /9/ und Griss /12/ haben auf die methodo- 
10gischen Vorteile disser Anweisungstypen hingewiesen. In 
tinserem Beisplel sind sie dadurch entstanden, daß die Trans- 
formationsregel nicht auf eine Funktion mit einem Parameter 
söndern äuf eine Funktion mit mehreren (2) Parametern ange- 
wendet wurde, Das Ergebnis der Prögrammtransformation wird 
nöch deutlicher, werin mat sich die bedingte Anweisime der 
Zeilen (6-8) äls eins Zuweisung eines bedingten Ausdrucks 
vorstellt 
(iwb,upb) t= if ((iwb+upb)/2)® en 

then ((1vb+upb)/2, upb) 

else (1vb, (1wb+upb)/2) 

#4 


dı Auch auf prossduralem Niveau des Gesamtalgorithmus können 
einzelne Komponshten applikativen bzw, deskriptiven Charakter 
tragen, In unseren Fall der Teilausdruck obere_schranke . DJ 
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Der .Algorithnus ist jedoch noch nicht genügend effektiv: 

in jedem Zyklusdurchlauf muß das Quadrat einer Zahl neu 
berechnet. werden. Durch formale Integration des. Zykluskörpers 
erhält man die Variablensubstitution 


= (Prgsr) "ger (Imb?, Iwbz(upb-1wb), (upb-Iwb)?) 


Wir. wenden diese Variablensubstitution auf das Programm an 
und erhalten: 


( 1) fünction isgrt(n: integer/ n>D): integer; 

(2) var P,q,r: integer; - 

( 3) begin (p,g,r) := (0, 0, obere_schranke?); 

(4) while r#1 do begin 

(5) assert( P£n<p+2zgtr & g’=pzr & power_of_%(r) ); 
( 6) if p+g+r/4&n 

(N then (p,q,r):= (p+g+r/4, q/2+r/4, r/4) 
( 8) else (p,q,r):= (p, q/2, r/4) 

( 9) endj 

(10) isgrt:=q 

(11) end 

(12) xher 

(13) „function obere_schranke:. integer 

(14) = 2zsone(i: integer/ 4z=z21>n); 

(15) predicate power_of_4(x: integer) 

(16) = lone(i: integer/ x=42=i ) 


(17) end fisgrt] 


Als nächstes betrachten wir nun die bedingte Anweisung im 
Zykluskörper. Es scheint offensichtlich, daß sich durch 
Sequentialisierung und Ausklammerung (Vorausberechnung) von 
Teilausdrücker einiges vereinfachen läßt: 


var 8: ‚integer; 
begin r:=r/4; 9:=p+q+r; q:=q/2;5 
if ssn 
then begin p:»s; q:=qg+r end 
end 


Als letzten Schritt müssen wir jetzt noch den Teilausdruck. 
obere_schranke ‘implementieren. Wir geben gleich die iterative 
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Fassung an: 


( 1) function isqrt(n: integer/ n20): Integer; 


(2) zwar p,q,7,8: Integer; 

( 3) begin pı=0; q:=0; rı=1; 

( 4) while r£&n do. 

(5) begin assert( power_of_4(r) ); r:=r24 end 
(6) while rf1 do 

(7) begin assert( pen<p+2zgır & ge=per & 
( 8) power_of_4(r) ); 

(9) 5 r:=r/A; S:=p-gtr; qgi=q/2; 

(10) if s<n 

(19) then begin pı=s; q:=q+r end 

(12) end; 

(13) isgrt:=q 

(14) end 


(15) where 

(16) predioate power_of_4(x: integer) 
(17) = lone( is integer/ x-4zsi ) 
(18) end fisart) 


Dieses Programm zur Berechnung der ganzzahligen Wurzel 
erfüllt nun wirklich alle Anforderungen, die wir an ein. 
effektives und zugleich wohl strukturiertes Programm stellen. 
Doch es hat es in sich. Vor einigen Jahren stellte uns 
A.Blikle die Aufgabe, dieses Programm (ohne die Zyklusinva- 
rianten versteht sich) nit Hilfe von Verifikationsstrategien 
"zuknacken'" = vergeblich waren alle Bemühungen. Probieren Sie 
es aus: stellen Sie einem Ihrer Kollegen die Knobelaufgabe, 
die Funktionsweise dieses Programms zu ergründen! 

Überschaut man rlickblickend den Entwurfsprozess, so sind 
nur an zwei Stellen wirklich wichtige Entscheidungen getroffen 
worden: zuerst bei der Auswahl der Methode der Intervallschach- 
telungen, später dann der Übergang zum Varlablensysten (p,g,r). 
Derartige Entscheidungen fallen nicht vom Himmel, sonderü 
erfordern einen gehörigen Schuß Intuition und auch Mut, einen 
Ansatz einfach auszuprobieren. Beides kann uns der Rechner 
nicht abnehmen. Programmieren ist und bleibt immer eine krea- 
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tive Tütigkeit’- es kommt nur darauf en, die "nervtötenden"' 
monotonen Teilprozesse zu bezwingen. | 

Breitbandsprachen und Programmtransformationen sind viel- 
leicht ein Weg, um auf dieser Strecke weiter zu kommen, Den 
unbestreitbaren Vorteilen, die sich aus dem Einsatz von Ereit- 
bandsprachen für die gesamte Technologie der Programmentwicklung 
ergeben, stehen jedoch erhebliche Akzeptanzprobleme gegenüber. 
Sie resultieren vor allem daraus, daß derartige neue, formale 
Sprachen als Kommunikationsmittel weniger geeignet sind als 
die althergebrachten, meist informalen (grafischen oder auch 
tabellarischen), für konkrete Anwendungsfälle bereits aufberei- 
teten sprachlichen Mittel. Eine weitere Ursache dürfte jedoch 
auch darin liegen, daß die zugrunde liegenden Kalklile der 
formalen Logik und der diskreten Mathematik von den heute in 
der Praxis tätigen Programmierern nicht (mehr) im notwendigen 
Maße beherrscht werden. 

Breitbandsprachen werden sich nur dann einen Platz als 
Programmie rhilsmittel erobern und behaupten können, wenn ihre 
Anwendung methodisch in geeigneter Weise aufbereitet wird, 
und wenn die bislang nur für kleine Beispiele demonstrierte 
Rechnerunterstützung auf der Basis von Programmtransformationen 
/11/ ökonomisch für breite Anwendungen vertretbar wird. 
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Verwendung des SM4-Makroassemblers als Übersetzer 
für einfache. problemiorientierte Sprachen 


1, Aufgabenstellung 


In der DDR werden in breitem Maße Mikrorechner mit einer Verar- 
beitungsbreite von & Bit auf Basis des GPU-Schaltkreises U 880 
eingesetzt, Ein wichtiger Aspekt ist dabei die Erstellung der 
Anwendunsssoftware, 


Zur Mikrorechnerprosramnierung können Entwicklungssysteme oder 
Wirtsrechner eingesetzt werden, In den Systemunterlagen werden 
‚vor allem Assembler, z.T.- mit Makroprozessor angeboten. Compiler 
für höhere Programmiersprachen stehen kaum zur Verfügung bzw, 
sind nur eingeschränkt nutzbar: BASIC kann für Echtzeitaufgaben 
oftmals nicht eingesetzt werden [1]; ein PASCAL-Compiler wird 
derzeitig erarbeitet [2]; PL-M ist für den 8080 konzipiert [3] 
(beim U880 werden bei der Nutzung von PL-M Leistungspotenzen 
verschenkt). Darüber hinaus gibt es Arbeiten zu CDL-2 [4] und 
PL-Z [5]. Aus verschiedenen Gründen werden diese Sprachen für die 
Programmierung praktisch wenig senutzt (Verfügbarkeit, Vertrieb, 
Eigenschaften des Sprachkorzeptes, Eigenschaften der Compiler). 
Demgegenüber stcht für viele Anwendunssfälle die Forderung nach 
problemorientierte Sprachen, Die Implementierung von Übersetzern 
für problezorientierte Sprachen auf Basis der Assemblersprache 
erfordert einen hohen Aufwand, Im folgenden Soll eine andere, 
weniger aufwendige Implerentierungsmöglichkeit vorgestellt er- 
den, bei der die Makrotechnik eines entsprechenden leistunss- 
fähigen Makroassemblers auszenutzt wird. Ein solcher Makroassen- 
bler ist innerhalb des SKR auf den Rechnern SM 3/5 4 bzw. K 1500 
gegeben [5]. 


2, Lösungsprinzip 


Bei der Implementierung eines Übersetzers nach dem vorgeschlase- 
nen Prinzip ergibt sich folsender Aufbau der Pro.;rammebenen: 
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Anwenderprogramm 


= ö e “mm 0 Gimme 4 mm ı mm me 


—: 


Interface z. 
Anwender- 
pragramm 


Makrobibliothek 


SM ! 
Wirtsrechner 


UP-Adressierg. 


Zielrechner 
K 1520 | 


Datenstrukturen Operationen 


| (1m. 


— . 


Parameter-Adr. 


Interface 
z,Zielrechner 


Unterprogrammbibliothek 


Datenstrukturen 


In der untersten Ebene werden die Datenstrukturen definiert, mit 
denen eine programntechnische Lösung der Problemklasse realisiert 
werden kann, Für regelungstechnische Aufzabenstellungen müssen 
z.B, die Zahlenformate der Arithmetik und die Darstellung der 
Zahlen als Bitmuster festgelegt werden. 


Auf diesen Datenstrukturen werden Funktionen definiert (z,B, 
arithmetische Operationen), Diese Funktionen müssen als Progran- 
me für den Zielrechner implementiert werden (Unterprogrannbib- 
liothek),. Auf die Datenstrukturen kann dabei nur über die ent- 
sprechenden Funktions-Unterprogramzme zugegriffen werden (objekt- 
orientierter Entwurf), 


Der Übersetzer muß in der Lage sein, den im problemorientierten 
Anwenderprozramm formulierten Algorithmus in eine Sequenz aus- 
führbarer BeTehle zu übersetzen, die die Parameterübergaben zwi- 
schen den Unterprogrammen sowie den Aufruf der Unterprosranre re- 
ellsieren. Dazu zenüsen einfache Befehle (Unterprogramm-Aufruf, 
Ladebefehle mit indirekter oder indexierter Adressierung usw.), 

dle sich für andere Zielrechnertypen problemlos austauschen lassen, 


Auf dem Wirtsrechner werden alle innerhalb der Sprache definierten 
Anwelsungen in Form von liakrös vereinbart, in denen jeweils die 
Befehlscodes der Maschinenbefehle des Zielrechners als Byte- bzw, 
Adreßkonstanten fixiert sind, 
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Das Anwendungsprogramm wird als Folge von Makrorufen geschrieben. 
Bei der Übersetzung mit dem Makroassembler erfolst die Syntax- 
prüfung mit den im Assembler implementierten Mitteln. Darüber 
hinaus können syntaktische Fehler nur erkannt werden, wenn bei 
der Implementierung der Makrobibliothek entsprechende Kontrollen 
vorgesehen. wurden. 5 


Zusammenfassen seien die verschiedenen Entwurfs- und Programnier- 
schritte genannt: 


A. Definition der Datenstrukturen im Zielrechner 

2. Definitionen der Operationen im Zielrechner, die auf 
die Datenstrukturen gerichtet sind 

3. Definition des Interface zun Wirtsrechner 

4, Implementierung der Prosranmme zu 1. bis 3. 

5. Implementierung eines Laders für den Zielrechner bzw, 
eines Nachübersetzers für den Wirtsrechner (zum Laden 
des Task-Image-Files im Mikrorechner bzw. zur Generie- 
runs des Standard-Lade-Formates für Mikrorechner im 
Wirtsreckner). 


Machen sich im Prozeß der Anwendervrograrnierung Änderungen / 
Erweiterungen eines einmal implementierten Konzeptes erforder- 
lich, so zrüssen in der Rezel nur die entsprechenden neuen Daten- 
strukturen und Operationen bereitzestellt werden (Ergänzungen der 
Unterprosrammpibliothek. und Erweiterungen der Makrobibliothek). 
Demit ist prinzipiell eine Kompatibilität der ? 
Schnittstelle zum Anwender gesichert, 


ro;ramme an der 


Ein Beis iels Nutzunz einer Gleitkomraarithmetik 


- 


Für Ecntzeit-Steuerunssaufsaben wird eine schnelle, register- 
orientierte Gleitkomnaarithnetik benötigt [7]. Als Datenfornat 
wird sine 3-Syte-Darstellunz (2 Byte Mantisse, 1 Byte Exponent) 
Testselest. 

Zseistellice Gleitkommaoperationen (zB. Addition) haben zwei, 
Eingabeozerarden und einen Ausgabeoperanden, Operanden werden 
nicht direkt übergeben, sondern es werden die Adressen der Ope- 
randen übergeben. In einem Assenblerprogramm für den X 1520 
könnte folgende Befehlsfolze vereinbart werden; 
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4 VEREINBARUNG DER DATENSTRUXTUR F. 1. OPER. 
AR: DA x ; ADRTSSE DES 1. OPER, 
X: BER 3 ı 3 BEE TUER 1. OPER, 
; VEREINBARUNG DER DATENSTRUZTUR F. 2. OPER, u 
AX2: DA x2 

Y2; BER 3 

$ VEREINBARUNG DER DATENSTRUXTUR F, ERGEBNIS 
AERG: DA ERG 

ERG: BER 3 

; BERECHNUNG VON ERG s= 1. OPER, + 2. OPER, 

$ PARANFTZRÜBERGABEN 


LD BC ,(AXA) 
LD DE ,(AX2) 
LD HL,(AERG) 


3 AUFRUF DES UNTERPROGR,. ZUR GLEITKONMAADD, 


CALL FTADD 


Mit zwei Makros auf Ebene der SM4-Assemblersprache lassen sich 
die Sequenzen zur Vereinbarung von REAL-Variablen und zum Aufruf 
des Unterprogramnes erzeugens 


NAMES 


„MACR REAL NAME 


‚WORD .+2 ; ADRESSZEIGER ZUR VARIABLEN 
.BUKEB 7 ; 3 BYTE FUEZR VARIABLE 

„EVEN 

„EiNDM 


.MACR ADD oPA ,OP2 ,2 
„EVEN 

.VORD 45755 ,0P1 
„WORD 55755,0F2 
.TORD 25000 ,2 


GENERIER, V. LD 20,(0P1) 
GEIERIER, V, LD DE,(OP2) 
GEN. V. HOP 

LD HL,(ERS) 
GEN, V. NOP 

CALL FTADD 


=. so b 7 =. En 


„ORD 145400,TFTADD 


(Die Einfügung von „EVEN sowie von Leerbefehlen OP ist erforde- 
lich, weil in der Assemblersprache der St!4 Adresszörte nur auf? 
geraden Speicheradressen vereinbart werden können. Bei Verwen- 
dung eines weiteren Hakros, der die Vereinbarung von Worten auch 
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auf ungeraden Adressen realisiert, kann die Einfügung entfallen,) 


Das Anwendunbsprogramm kann unter Verwendung dieser Makros wie 
folgt geschrieben werdens 


.MCALL REAL,ADD 


REAL 7 M 

REAL X2 

REAL ERG 

ADD X1,X2, ERG 
„END 


In gleicher Weise können Makros für andere Datentypen und Opera- 
tionen vereinbart werden. 


4, Implementierungsvarianten 


Das dargestellte Prinzip kann mit verschiedenen Implementierungs- 
varianten realisiert werden, Die im Beispiel verwendete indirekte 
Operandenadressierung ist für die Vereinbarung dynamischer Felder 
erforderlich, Außerdem ist die indirekte Adressierung Voraussetzung 
für die Überprüfung von Zugriffsrechten in den Unterprogramnen. 


Wenn Anwenderprogramme ausschließlich aus Unterprogramnmaufrufen 
bestehen, kann der Befehlscode für den Befehl 'CALL! eingespart 
werden. Auch die sich wiederholenden Befehlscodes für die Indirekt- 
Ladebefehle können entfallen. Das Anwenderprogramm besteht dann 
nur noch aus einer Folge von Adressen, die zu den Parametern und 
den Unterprogrammen vermitteln. Die Programmsteuerung muß von 
einem Interpreter übernommen werden, Für den Mikrorechner K 1520 
benötigst ein derartizer Interpreter pro Schleifendurchlauf (d.h. 
für eine zu interpretierende Adresse) ca, 60 Takte gezenüber 

17 Takte bei einer direkten Programmierung über CALL-Befehle, 

Die Speicherplatzeinsparung beträgt 30...50% gegenüber einer in 
Makros formulierten vollständigen Assemblerprogramnierung, Dieses 
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Implementierungsprinzip wird mit “threaded code" bezeichnet und 
im Zusammenhang mit leistungsfähigen, maschinenunabhängigen und 
wenig speicherplatzintensiven Compilerlösungen diskutiert [8]. 


Wenn die Anzahl der Operanden und Funktionen auf weniger als 256 
beschränkt ist, kann ein weiteres Niveau der indirekten Adressie- 
rung zwischengeschaltet werden, Parameter und Operationen werden 
dabei nur noch durch ein Byte charekterisiert, Der Interpreta- 
tionsaufwand liegt bei etwa 120 Takten je Schleife, Der Speicher- 
platzbedarf des Anwendungsprogrammes reduziert sich um ca, 50 bis 
70%. Wenn die Unterprogramme des Basis-Software-Paketes (unterste 
Softwareebene in Bild 1) verschieblich programmiert sind, kann die 
Makrobibliothek um die Maschinenbefehle (Codes) der Unterprogramme 
erweitert werden. Bei jeder erstmaligen Verwendung der Makros wird 
das erforderliche Unterprogramm in einem Bibliotheksbereich wäh- 
rend der Assemblierung generiert, Damit erhält man eine abgeschlos- 
sene, redundanzfreie Prosrammversion für das Mikrorechner-Anwen- 
dungssysten. 


5, Vor- und Nachteile der vorgeschlagenen Lösung 
Die vorgeschlagene Lösung hat folgende Vorteiles 


1. Ähnlich wie in einigen modernen Programmiersprachen (GDL-2)[4] 
wird der Programmierer zu einer logischen Vorgehensweise bei 
der Problemspezifikation und bei der Prozrammierung gezwungen, 
wodurch saubere Schnittstellendefinitionen entstehen, Auf den 
verschiedenen- Entwurfsebenen werden dabei Entwurfsentscheidun- 
sen gesenüber darüberliegenden Ebenen verborzen (objektorien- 
tierter Software-Entwurf). Damit wird insbesondere den Forde- 
rungen nach Modularität, Portabilität und Erweiterbarkeit von 
Prosranmen Rechnung getragen, Bei Übertragung von Anwender- 
prograrmen auf andere Zielrechner müssen die entsprechenden 
Unterprograrme für den Zielrechner erstellt sowie die Maschi- 
nencodes in den Operations-akros geändert werden. Eine Ände- 
rung der Anvendersoft'are ist nicht eroräsrlich, 


2. Die Implementierung des Übersetzers wird verein?acht, Der Sii4.. 
akroassembler übernimmt die Syntaxprüfuns, 


3. Der Prozramnierer hat freie Hand bei der Implementierung von 
Compile-Time-(in den Makros realisiert) bzr. Run-Time-(in’ den 
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Unterpro;rammen realisiert) Fehlerkontrollen. Das kann bis zur 
Überwachung von Zugriffsrechten auf bestimste Datentypen seitens 
der Operationen gehen, 


Folgende Nachteile sind festzustellen: 


1. Die sprachlichen Ausdrucksmittel von auf diesem Wege imrlemen- 
tierten Übersetzern für einfache problemorientierte Sprachen 
sind gering. 


2, Bei der Imxzlementierung beliebiger Datenstrukturen und Opera- 
tionen stehen nur wenige Freiheitsgrade zur Verfügung. 


3. Die Quelltextgestaltung ist durch die Anforderungen aus der 
Makro-Assemblersprache bereits fixiert (z.B, sind Namen nur auf 
max, 56 Zeichen auswertbar). 


Trotz dieser Nachteile wird eingeschätzt, daß für einfache Pro- 
bleme die vorgeschlagene Lösung vorteilhaft ist -— insbesondere 
wegen der unkomplizierten und Schnellen Implementierbarkeit der 
Übersetzer. 
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TESYS -— Ein technologisches System zur Software-Entwicklung 


1. Einleitung 


Der ständig steigende Bedarf an Software erfordert eine dement- 
sprechende Produktivitätssteigerung durch Rationalisierung und 
Effektivierung auf dem Gebiet der Softwareentwicklung, Das wis- 
senschaftliche Aufbereiten dieses Gebietes im Sinne einer Inge- 
nieurwissenscheft führte zu einer Anzahl neuer Methoden, Verfah- 
ren und Werkzeugen, Ihre Anwendung sowie das Nutzen vorhandener 
Lösungen im Sinne standardisierter Bausteine führt jedoch nur 
dann zu den beabsichtigten Zielen, wenn die Hittel aufeinander 
abgestimmt sind, d. h. konfliktfrei miteinander korrespondieren 
und auch an die spezifischen Bedingungen des Anwenders anpaßber 
sind. TESYS stellt eine solche rechnergestützte Lösung für die 
Zielsprachen PL1 und COBOL in Form von Prozessoren dar, 


2. Bestandteile von TESYS 


Eine Übersicht über die Bestandteile von TESYS gibt Bild’1, 
Eine wichtige programmtechnische Basis stellt der Makroprozes- 
sor dar. Er ermöglicht sowohl die angepaßte Nutzung der in der 
Methodenbank mitgelieferten Systembestandteile durch die übri- 
gen Prozessoren, als auch das Speichern und Aufrufen von An- 
wenderalgorithmen. Sie können im Sinne bekannter Nittel der 
Makrotechnik modifiziert und auch entsprechend ihrer Zugehörig- 
keit zu TESYS-Bausteinen umgeordnet werden, Der NMakroprozessor 
kenn auch eigenständig für beliebige Zielsysteme, z. B, als 
Job-Control-Generator, genutzt werden, 


Der Programnstrukturprozessor generiert auf der Grundlage der 
Zielsprachendefinition ein Programmskelett, in das an markier- 
ten Stellen Bausteine eingefügt werden. In die Bausteine zu 
übernehmende Quelltexte oder weitere Bausteine werden durch 
den Prozessor aus den Eingabestrom gesammelt und mit Hilfe der 
Namenskonvention in die vorgesehene Stelle eingeordnet, Bau- 
steinnerken können auch anwenderspezifisch gesetzt werden. Für 
Programme mit Phasenstruktur wird ein Phasenskelett bereitge- 
stellt. 


Bild 1 
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Beim Prozessor für Strukturierte Programmierung können mit ei- 
nem Pseudocode die Konstrukte 

- Reihung 

- Fallunterscheidung 

- \iiederholung und 

- Verlassen | 

genutzt werden. Da auch freie Texte zugelassen sind, können 
strukturierter Entwurf und strukturierte Dokumentation auf: lo- 
gische Richtigkeit maschinell getestet werden, Für die Codege- 
nerierung dürfen Strukturblöcke nur noch Pseudocode und Ziel- 
sprachencode enthalten. 


Datenorientiertes äntwerfen und Implementieren nach Jackson ein- 
schließlich Programmierversion und Backtracking sind durch Nut- 
zen von Programmstrukturprozessor und Prozessor für Strukturier- 
te Programmierung möglich, 


Der Entscheidungstabellenprozessor führt auch für freisprachlich 
formulierte Bedingungen und Aktionen die formale Strukturanalyse 
und Vollständigkeitsprüfung aus. Zur Generierung von Quellcode 
müssen Bedingungen und Aktionen in der Zielsprache oder als 
Pseudocode vorliegen, Entscheidungstabellen ‚können sowohl eigen- 
ständig, als auch als Block der Strukturierten Programmierung 
eingesetzt werden, 


Der Satzgruppenverarbeitungsprozessor erzeugt für die Verarbei- 
tung von logisch sequentiellen Dateien auf der Grundlage des 
wechsels im Gruppenbegriff Programmskelette und fügt die vom 
Anwender codierten ‚Bausteine anhand vereinbarter Namen. in das 
jeweils erzeugte Skelett ein. Das Mischen von Dateien und das 
Verarbeiten von Sekundärdateien bei Gruppenwechsel der steuern- 
den Datei ist möglich. 


Wit dem Dateiprozessor kann die Datenunabhängigkeit der Verar- 
beitung gesichert werden. Durch den Makroaufruf, der Definitio- 
nen und Frogranmskelette erzeugt, wird eine funktionsorientier- 
te Schnittstelle zum Anwender gebildet, Werden die Namenskon- 
ventionen für Daten, Routinen und Bausteine eingehalten, sind 
beliebige Dateisysteme anschließbar, 
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Datensätze werden in einfacher Syntax beschrieben. Der Daten- 
satzbeschreibungsprozessor erzeugt zielsprachengerechte Defi- 
nitionen, maschinell auswertbare Dokumentationssätze und forma- 
tierte Listen, 


Darüber hinaus erzeugt der Ausgabesatzbeschreibungsprozessor 
auch Übertragungsanweisungen, wenn die Herkunft der Elemente 
elnes Ausgabesatzes als Eingabedatum, Rechenergebnis oder Kon- 
stante angegeben ist. Der Anwendung dieses Prozessors sind 
kaum Grenzen gesetzt, da Definitionen und Verarbeitungsanwei- 
sungen der Zielsprache eingesetzt werden können. 


Der Listenprozessor ermöglicht das Beschreiben von Zeilen für 
Listenkopf, Listenfuß, Seitenkopf, Seitenfuß sowie von gruppen- 
abhängigen Zeilen und Einzelzeilen, Spaltensummenbildung, Ta- 
bellenausgabe und gruppenabhängige Ausgabeunterdrückung ist 
möglich. Sehr günstig ist die Ausgabe von Pseudolisten anhand 
der Definition, 


Mit den Prozessoren des Dokumentationssystems können hierar- 
chisch strukturierte Dokumentationen, Verzeichnisse, Verwen- 
dungsnachweise u. a. ausgegeben werden. Die Dokumentationen 
können aus Beständen der Textbibliothek, Programmbibliothek 
und Dokumentationsbibliothek zusammengetragen werden, Sie wer- 
den mit Seltennummerierung, Kapitelüberschriften, Sachwortver- 
zeichnis und Inhaltsverzeichnis’ versehen, Verwendungsnachweise 
u. ä, lassen sich aus den von den übrigen Prozessoren erzeug- 
ten Dokumentationssätzen ableiten. Die Ausgabe des Dokumenta- 
tionssystems kann über ein Konvertierungprogramm dem Textver- 
arbeitungssystem TVS/S zugeführt werden. 


3 Wirkungsweise von TESYS 


Die Prozessoren werden über TESYS-Anweisungen aktiviert, Sie 
stellen Anweisungen mit großer Hächtigkeit, d. h. hohem Pro- 
blemgehalt. dar, Parameter, die Standardwerten entsprechen, 
brauchen nicht spezifiziert zu werden, Es gibt System-, Datei- 
und Dokumentatißnsparameter, denen Standardwerte zugewiesen 
werden können. Diese lassen sich beim TESYS-Aufruf oder in den 
TESYS-Anweisungen modifizieren. 


280 


Die Prozessoren erzeugen entweder parametergesteuert direkt Code 
oder bilden ihn durch Aufruf von NWakros aus der liethodenbank. 
Letztere können vom Anwender modifiziert oder ersetzt werden, 
Tbenfalls lassen sich eigene Makros einfügen. In gleicher Weise 
können zu den Standardbausteinen- von TESYS weitere hinzugefügt 
und mit Code gefüllt werden. In der Methodenbank können außer 
Zielsprachencode, Pseudocode,-TESYS-Anweisungen auch freie Texte 


abgespeichert sein. 


Die in TESYS vorgesehenen Dokumentationssätze lassen sich auch 
um anwenderspezifische erweitern, Abgesehen von den Prozessoren 
des Dokumentetionssystems erzeugen alle Prozessoren Zielspra- 
chencode, Dokumentationssätze und aufbereitete Listen, 


4, Vorteile der TESYS-Anwendung 


Die große kächtigkelt der TESYS-Anweisungen und die Nutzung än- 
derbarer Standardparameter ermöglicht einen geringen Umfang der 
vom Anwender vorzunehnmenden Spezifikation, Alle ableitbaren An- 
gaben werden von den Prozessoren erzeugt, Die Integration der 
Prozessoren gewährleistet die Paßfähigkeit untereinander und 
eine hohe Zuverlässigkeit. Das Bausteinprinzip ermöglicht eine 
funktionsorientierte Betrachtungsweise über den gesamten Ent- 
wicklungszeitraun, also auch in der Implementierungsphase, weil 
funktionell zusammengehörender Code unabhängig von der erforder- 
lichen Stellung im Programm notiert werden kann und TESYS die 
Umordnung mit Hilfe der Bausteinnamen vornimmt, Außerdem wird 
durch die liethodenbank die Wiederverwendung von Lösungen im 
Sinne von Standardbvausteinen gefördert. Die Mittel von TESYS ge- 
statten auch eine standardisierte Anwendung von Vorgehensweisen, 
Namen u. a. vorzugeben und zu kontrollieren, 
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Ein allgemeines Steuerprogramm zur sequentiellen Auswertung von 
Dateien 


Aufgabenstellung und Anliegen des Programns: 

Die sequentielle Auswertung von Dateien ist eine typische Aufgabe 
für Projekte der Planung, Leitung und Kontrolle. Im Verlaufe der 
Lösung solcher Aufgaben werden eine oder mehrere Dateien sequen- 
tiell gelesen, wobei das Lesen der Sätze dieser Dateien anhand 
eines Ordnungsbegriffs, der diesen Dateien gemeinsam ist, und 
nach dem die Dateien sortiert sind, synchronisiert wird. Die Da- 
ten der Sätze mit gleichem Ordnungsbegriff werden miteinander 
"verknüpft und auf eine oder mehrere Dateien, ebenfalls sequen- 
'tiell, geschrieben. Auch den im Speicher der EDVA auftretenden 
Zwischenergebnissen läßt sich ein entsprechender Ordnungsbegriff 
zuweisen. Die Reihenfolge der Verarbeitung der einzelnen Sätze 
ist durch eine aufsteigende Folge dieses Ordnungsbegriffs gegeben. 
Insgesamt wird der Verarbeitungsprozeß durch die im Verlaufe der 
Bearbeitung auftretenden Dateneinheiten (Strukturen) und ihre zu- 
gehörigen Ordnungsbegriffe bestimmt. Die Verarbeitung läßt sich 
in eine gewisse Zahl von Teilprozessen auflösen, die durch ent- 
sprechende Teilprogramme (Module) realisiert werden. Jeder dieser 
Module benötigt jeweils ganz bestimmte Strukturen als Datenquel- 
len, beziehungsweise Datensenken. Die Koordinierung der Teilpro- 
zesse in Form eines Ansteuerns der verschiedenen Module läßt sich 
durch ein allgemeines Steuerprogramm durchführen, das unabhängig 
von den speziell zu lösenden Aufgaben ist. Die Module werden von 
steuernden Programmfunktionen weitgehend entlastet. Die verschie- 
denen Module werden vom Steuerprogramm als unabhängig voneinander 
betrachtet. Sie stehen lediglich über ihre Ein- und Ausgabestruk- 
turen miteinander in Verbindung. 


Steuerblöcke: 

Das Steuerprogramm unterscheidet 3 Typen von Objekten: Strukturen, 
Module, Dateien. Jedes dieser Objekte wird durch einen Steuer- 
block charakterisiert. 
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Struktur: 

Das Steuerprogramm erhält mit Hilfe des Steuerblocks Namen und 
Adresse der Struktur, eine Vorschrift zur Bildung des zugehöri- 
gen Ordnungsbegriffs und eine Liste spezieller Module, die der 
Initielisierung oder Finalbearbeitung der Struktur dienen. Vom 
Steuerprogramm wird ein Zähler (Existenz) bereitgestellt, der 

die Zahl der Module angibt, die. diese Struktur als Ausgabestruk- 
tur benutzen und zum betreffenden Ordnungsbegriff auch tatsäch- 
lich die Steuerung hatten. Der Zähler ist zur Kommunikation des 
Steuerprogramms mit den Modulen oder der Module untereinander 
gedacht. Das Steuerprogramm benutzt für seine eigenen Zwecke 

zwei weitere Zähler, un die Freigabe oder Blockierung der Struktu- 
ren für Ein- oder Ausgabeoperationen der Module zu regeln. 

Modul: 

Das Steuerprogramm erhält mit Hilfe des Steuerblocks Namen und 
Adresse des Moduls, eine Liste der Eingabestrukturen und eine Li- 
ste der Ausgabestrukturen des Moduls. Vom Steuerprogremm wird ein 
‚Zähler (Existenz) bereitgestellt, der die Zahl der zum aktuellen 
Ordnungsbegriff tatsächlich existierenden Eingabestrukturen des 
Moduls (d.h. Strukturen mit einem Existenzzähler größer als Null) 
angibt. Auch mit Hilfe dieses. Zählers kann eine Kommunikation des 
Steuerprogramms mit. den Modulen oder der Module ‚untereinander er- 
folgen. 


Datei: 

Dem Steuerprogramm werden mit Hilfe dieses Steuerblocks Namen 
(DD-Name), Steuerblockadresse (DCB) und Typ der Datei, sowie die 
zugehörigen Ein- oder Ausgabestrukturen mitgeteilt. 


Realisierung: 

Das Programm ist für ESER-Anlagen unter Steuerung des Betriebssy- 
stems OS bestimmt. Die Angaben zu den Steuerblöcken werden in 
Form von Assembler-Makros gemacht. Module werden in PLi formu- 
liert. Sie beginnen mit dem Modulnamen als Narke und enden mit 
einem Sprungbefehl unter Benutzung einer allen Modulen gemeinsa- 
men Label-Variablen. 

Mit Hilfe der Angaben zu den Steuerblöcken und des PL1-Quelltex- 
tes der Module wird ein kompletter PLi-Programmtext erzeugt, der 
neben den Algorithmen der Module und den Deklarationen der vom 
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Steuerprogramm zu verwaltenden Strukturen, die Deklarationen der 
Steuerblöcke enthält, FLi1-Compiler und Programmverbinder erzeu- 
gen aus diesem Quelltext das Verarbeitungsprogramm, das in der 
nächsten Phase, der eigentlichen Aufgabenlösung, zur Ausführung 
gelangt. 


Programmablauf: 

Das Verarbeitungsprogramm erhält die Steuerung, initialisiert die 
Steuerblöcke und stellt die für alle zur Abarbeitung gelangenden 
Module gleiche PL1-Ungebung her. Danach wird die Steuerung an’ das 
Steuerprogramm abgegeben. Das Steuerprogramm fixiert die PL1-Um- 
gebung und koordiniert mit Hilfe der Steuerblöcke und verschiede- 
ner Wartelisten die Zusammenarbeit der Module. Ein Modul wird an- 
gesteuert, falls alle seine Eingabestrukturen für die Eingabe und 
alle seine Ausgabestrukturen für die Ausgabe frei. sind. Dieser 
Zustand wird durch einen Wert größer -als Null für die betreffen- 
den Zähler angezeigt. Umgekehrt haben dann die Zähler für Ausgabe 
und für Eingabe dieser Strukturen einen Wert gleich Null. 
Bevor einem Modul die Steuerung übergeben wird, stellt das Steu- 
erprogramm die vom Modul benötigte PL1-Umgebung her und weist der 
Labelvariablen, mit deren Hilfe der Rücksprung aus dem Modul er- 
folgt, einen dem Steuerprogramm entsprechenden Wert zu. Nach 
Rückgabe der Steuerung durch den Modul werden entsprechend den 
erreichten Werten der Ordnungsbegriffe, die Zähler für Eingabe 
und Ausgabe der vom Modul benutzten Ein- und Ausgabestrukturen um 
Eins erniedrigt. Erreicht ein Zähler den Wert Null, werden die 
zur Struktur gehörigen Initial- oder Finalmodule angesteuert, Der 
Verarbeitungsprozeß endet, wenn für alle Eingabedateien die Da- 
teiendebedingung anliegt und allen internen Datenstrukturen der 
Ordnungsbegriff 'Ende! zugewiesen wurde. Das Steuerprogramm gibt 
dann die Steuerung an das Verarbeitungsprogramm zurück und dieses 
beendet seine Arbeit durch Rückgabe der Steuerung an das Betriebs- 


systen. 
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Programmierung und Nachnutzbarkeit 


Die Vorteile der Wiederverwendbarkeit von POS leuchten intuitiv 
unmittelbar ein, warum aber werden sie so wenig genutzt? Welche 
objektiven Gründe gibt es für die viel zu geringe Nachnutzung 
auf diesem Gebiet? 


Die Wiederverwendung von POS ist mit zwei grundlegenden Bedin- 
gungen verbunden: 


1. Gleichartige DV-Aufgaben müssen wiederholt auftreten. 
2. Nachnutzung muß ökonomisch vorteilhaft sein. 


Die erste Bedingung kann als notwendige, die zweite als hinrei- 
chende angesehen. werden. 


Wie steht es nun um die Erfüllung dieser Voraussetzungen? Das 
mehrfache Vorkommen gleichartiger DV-Aufgaben läßt sich beinahe 
täglich in der Praxis der Herstellung von Systemunterlagen (Pro- 
grammierung) sowohl im Kleinen als auch in größerem Rahmen beob- 
achten. Erinnert sei z.B. daran, daß unzählige Institutionen ihr 
eigenes Programmsystem zur Ermittlung von Lohn und Gehalt erar- 
beltet haben. 


Zu den ökonomischen Verhältnissen im Zusammenhang mit Software- 
herstellung sind in letzter Zeit zahlreiche Fakten zusammengetra- 
gen worden. Betrachtet man sie unter dem Blickwinkel der Nach- 
nutzung, ergeben sich zusätzliche Erkenntnisse. 


Die Kosten für eine Million Maschinenoperationen haben sich nach 
Hansen (1979) wie folgt entwickelt: 


1950 30,00 DM 
19709 0,30 DM 
1979 0,03 DM. 


Verbunden mit einer analogen Entwicklung der Kosten pro Spei- 
cherplatz vollzog sich die drastische Veränderung des so häufig 
zitierten Aufwandsverhältnisses von Hardware und Software. Es 
zeigt sich also, daß die insgesamt größeren Anteile zur Rationa- 
lisierung im Softwarebereich liegen. 
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Detaillierteren Aufschluß über die Möglichkeiten der Nachnutzung 
geben Aussagen Über den Herstellungsprozeß. Abbildung 1 ist eine 
Zusammenstellung statistischer Werte zur Fehlerentstehung und 
-erkennung während der Erarbeitung und des Einsatzes von Soft- 
ware (vgl. Ross 1976). 


Fehlerent- 


während ans nach 
der Abnahme 


Abb. 1 Fehlerentstehung und -erkennung 


Die Mehrzahl der Fehler (64 %) bei der Herstellung von Systemun- 
terlagen wird der Statistik zufolge in den Phasen vor der Codie- 
rung verursacht. 


Das belegt, daß der Entwurf von Programmsystemen der schwierige» 
re Teil des Gesamtprozesses ist und die sich dabei einschlei- 
chenden Unkorrektheiten besonders unangenehme Auswirkungen haben. 
Eine günstige Beeinflussung dieser Etappen auch durch Nachnutzung 
ist demnach besonders wünschenswert. Der Aufwand für die Beseiti- 
gung der Fehler, die während Codierung und Test verursacht wer- 
den, kann bei der Nachnutzung im allgemeinen gänzlich entfallen. 
Wie hoch dieser Anteil am Gesamtaufwand ist, zeigt die Abbil- 
dung 2 -— Aufwandsverteilung bei der Herstellung von Systemunter- 
lagen (vgl. Keßler 1981). 
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en 
Industrie- = 
'erprobung “ 20 
Korrektur + e . 
Test > 20 


Abb. 2 Aufwandsverteilung 


Somit wird deutlich, daß die Verhältnisse hinsichtlich der bei- 
den grundlegenden Bedingungen für die Nachnutzung günstig sind; 
der erreichte Faktor der wiederholten Verwendung aber ist nicht 
ausreichend. Diese Situation ist auf zwei wesentliche Ursachen 
zurückzuführen: 


1. Die Vielschichtigkeit der Nachnutzungsproblematik. 
2. Die fast ausschließliche Orientierung auf Enüprodukte 
der Programmierung. 


Eine eingehende Betrachtung der Problemstellung Nachnutzung führt 
zu drei bestimmenden Bereichen, die sich zum Teil stark voneinan- 
der unterscheiden und von denen jeder weiter untergliedert werden 
kann. 


Die Nachnutzung vorhandener Programme setzt voraus, daß deren 
Funktionen verstanden werden. Dieses Verstehen an Hand der Pro- 
gramme und deren Beschreibung als Endprudokte zu erreichen, er- 
weist sich in der Regel als sehr schwierig. Das bedeutet großen 
Aufwand. 
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erkenntnistheoretische Aspekte 


= inhaltliche Klassifizierung von DV-Auf- 
gaben 
(Operationen, Datenstrukturen) 

- Verstehen von Programmen 

- Zuverlässigkeit von Programmen 


Nachnutzung edv=technische Aspekte 


- Betriebssystemkomponenten 
(Programmiersprache, Verbinder, JCL;z.B. 
bei PP und PS des OS/ES) 

- Form der Flexibilität 
(Makros, Parametersteuerung, Exit-Progran- 
mierung) \ 


psychologische Aspekte 


- Geringschätzung nichtselbstgefertigter 
Programme 
- Vorbehalte gegen bestimmte Hersteller. 


Wenn es gelingt, den Prozeß der vorgenommenen Umformung einer 
Aufgabe in Programme Über markante Zwischenstationen nachvoll- 
ziehbar zu machen, kann das Verstehen entscheidend erleichtert 
werden. Für das Auffinden geeigneter Zwischenstationen ist dieser 
Prozeß der Überführung einer EDV-Aufgabe in Programme zu analy- 
sieren. Allgemein üblich ist es dabei, eine Einteilung in Phasen 
vorzunehmen; die einzelnen Ansätze unterscheiden sich in der Zahl 
der Teilabschnitte und ihren Bezeichnungen. 


Programmieren umfaßt im allgemeinen die Strukturierung von Funk- 

tionen und von Daten. Für die Strukturierung von ausschließlich 

Daten hat sich das Dreiebenenmodell bewährt. Das legt es nahe, 

dieses Modell auf die Programmierung als Gesamtheit anzuwenden. 
und Dreiubane ; 

Die Verknüpfung von Phaseneinteilung’ist In Abbildung 3 vorgenom- 

men worden, 


Das Dreiebenenmodell macht besonders deutlich, daß in den einzel- 
nen Programmierphasen unterschiedliche Produkte mit unterschied- 
lichen Ausdrucksmitteln entstehen, die in unterschiedlichem Maße 


25_Vers j 
Auecks Nachnutzung von Programmen oder auch von Zwischenprodukten 
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unterstützen können. Die Abschnitte der Programmierung, die zwi=- 
schen konzeptueller und interner Ebene liegen, werden gegenwärtig 


zunehmend automatisiert (Programmentwicklungssysteme). 


Programmierung 


Daten Operationen 


externe Ebene 


konzeptuelle 
Ebene 


interne Ebene 


SS dad) 


Abb. 3. Verknüpfung von Phasen- und Dreiebenenmodell 


Für die Nachnutzung von POS vorteilhaft können in besonderen 
Maße die Produkte sein, die im Bereich zwischen externer und kon- 
zeptueller Ebene erstellt werden. Als Beispiel dafür wird kurz 
auf die in Hansen (1979) vorgeschlagene problemorientierte Krite- 
rienliste eingegangen. 


Abbildung 4 zeigt einen Auszug einer solchen Liste für die Aufga- 
be Kostenrechnung. Diese Darstellung einer DV-Aufgabe und ihrer 
Teilaufgaben ermöglicht die Kommunikation unterschiedlicher Dis- 
kussionspartner, ohne spezifische DV-Kenntnisse bzw. Implementie- 
rungscharakteristika voraussetzen zu müssen. In der am weitesten 
rechts angeordreten Spalte wird für ein konkretes System ange- 
zeigt, welche Teilaufgabe realisiert ist bzw. welche Funktionen 
von einer einzurichtenden EDV-Anwendung ‚übernommen werden sollan. 
Derartige Kriterienlisten können das Ergebnis der Analyse einer 
Aufgabenstellung zur Herstellung bzw. Anwendung von Systemunter- 
lagen sein. Möglich sind dabei Untersuchungen im entsprechenden 
Fachbereich, ohne in diesem Stadium durch EDV-Spezifika belastet 
zu werden, 
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Kostenarten- 
rechnung 


Eingabe 1. Kostenübernahme aus Finanzbuch- 


2. Maximale Anzahl der 
j Mengeriangaben 
Zeitangaben 


Aus, 
Verarbeitung 1. Prüfung % Doppel- 
" belege 


2. Primärkostenver- 
buchung auf Kostenstellen 


Ausgabe 1. Abstimmlisten 


Erlösarten 
Abb. 4 Problemorientierte Kriterienliste 


Weiterhin kann eine so aufgebaute Aufgabenbeschreibung als Aus- 
gangspunkt für den Übergang vom WAS zum WIE angesehen werden. 
Diese Kriterienliste ist hierarchisch aufgebaut und‘läßt sich 
deshalb leicht als Struktur darstellen, wie sie in HIPO oder 

auch bei Jackson (1975) benutzt wird. Damit läßt sich demzufolge 
der Entwurf: entsprechender Systemunterlagen schrittweise dokumen- 
tieren. Diese Dokumentation kann dann bis zum gewünschten Verfei- 
nerungsgrad verfolgt werden, um z.B. erforderliche Anpassungen 
zum Zwecke der Nachnutzung vornehmen zu können. 


Zusdmmenfassend wird festgestellt, daß aufgrund der Vielschich- 
tigkeit der Problematik Nachnutzung eine spürbare Verbesserung 
der Situation nur durch ein ganzes Bündel von Maßnahmen erreicht 
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werden kann. Dabei ist es notwendig, daß entsprechend den jeweili- 
gen Gegebenheiten an der Weiterentwicklung der einen oder anderen 
Teilproblematik gearbeitet wird. Es müssen: jedoch Aktivitäten sol- 
cher Art in den Gesamtzusammenhang der Nachnutzungsaspekte einge- 
ordnet werden. Die Überbetonung einer Seite der Wiederverwendung 
bei Vernachlässigung der noch zahlreichen anderen führt zu unbe- 
friedigenden Ergebnissen. Die zielgerichtete Aufbereitung von 
Zwischenprodukten bei der Herstellung von Systemunterlagen kann 
eine Komponente zur Ausdehnung der Nachnutzung sein. 
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Kiesohke, Reiner 


Auswahlkriterien für die Anwendung vorgefertigter SKoftware der 
Dialogverarbeitung 


1. Einleitung 

Die Erarbeitung von dlalogorientierten Anwendungslösungen kann 
durch die Nutzung von vorgefertigter Software der Dialogverarbei- 
tung unterstützt werden. In Vortrag wurde dargelegt, wie diese 
Software in Abhängigkeit von den in ihr inplizierten Servicelei- 
stungen pro zu durchlaufender Programmschioht klassifiziert wer- 
den kann. Grundsätzlich sind bei der Abarbeitung eines Progrann- 
systems der Dialogverarbeltung folgende Progrannschichten zu 
durchlaufens 

- die Leit ungssteuerung, 

- die Nachrichtensteuerung und 

- die Nachrichtenverarbeitung. 


Gleichzeitig wurde in Vortrag aufgezeigt, unter welchen Bedingun- 
gen die so klassifizierte vorgefertigte Software der Dialogverar- 
beitung genutzt worden sollte, 


2. Im Data Management des Betriebssystems inplizierte 
Zonponenten 
‘Für die Betriebssystene ist charakteristisch, daß in ihnen zuneh- 
nond Serviooleistungen zur Unterstützung der Dialogverarbeitung 
enthalten sinä (vgl. ze B» /1/, /2/). Insbesondere das Data Mana- 
gement enthält Module, die für die Anwendung des Mensch-Maschi- 
ne-Dialoges (MMD) genutzt werden können. Das Data Management un- 
terstützt die unterste Programmschicht, die bei der Realisierung 
. des NMD zu durchlaufen ist — die Leitungssteuerung. Diese Soft- 
wareschicht bildet eine unmittelbare Schnittstelle mit der Hard- 
ware einer EDVA, 


Die Softwarekonponenten, die unter den Bedingungen der lokalen 
Datenverarbeitung (DV) zur Leitungssteuerung gehören, realisie- 
ren datenverarbeiltungsspezifische Funktionen, die für das Über- 
tragen von Daten von Terminal zur Zentraleinheit der EDVA und 
in ungelehrter Richtung notwendig sind, z. Bs 

- Abrufen der Daten von Terminal und Übermittlung dieser Daten 
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zur EDVA; 

- Zustandsüberprüfung des Terminals und der Übersetzungsleitun- 
gen; 

- Einleitung von Fehlermaßnahmen. bei fehlerhafter Datenübertra- 
gung zwischen dem Terminal und der EDVA; 

- Übergabe der Ausgabedaten eines Nachrichtenverarbeitungspro- 
grams (Problemprogram) an die Ausgaberoutinen der Datenver- 
waltung zur Übermittlung an das adressierte_Terminal; 

- Weiterleitung der Eingabedaten vom Terminal an das entspre- 
chende Nachrichtenverarbeitungsprogramn; 

- Verwaltung von Warteschlangen bezüglich der Ein- und/oder 
Ausgabodaten -und der benötigten Nachrichtenverarbeitungspro- 
granmne. 


Das Anfordern von Serviceleistungen des Betriebssystems für die 
Unterstützung des MMD unter lokalen Bedingungen setzt detail- 
lierte Programmierkenntnisse voraus, in der Regel in der Pro- 
grammiersprache, auf deren Grundlage das betreffende Betriebs- 
system programmiert wurde. Unter den Bedingungen der Anwendung 
von ESER-Rechnern müssen Programme für die Dialogverarbeitung 
beispielsweise in ASSEMBLER programmiert werden, um die Leilstun- 
gen des Betriebssystems für die Realisierung des MMD nutzen zu 
können. Hierfür sind spezielle imperative und deklarierende Ya- 
kros zu verwenden und die Zustände von Bits in Steuerblöcken 
abzutesten, die vom Betriebssystem in den Programmen für den 
NMD definiert werden. 


Soll dis Realisierung des NMD sowohl unter den Bedingungen der 
lokalen Datenverarbeitung als auch der Datenfernverärbeitung 
(DFV) möglich sein, können ebenfalls Serviceleistungen des Be- 
triebssystems für die DFV bezüglich der Datenverwaltung genutzt 
werden. Diese Leistungen werden vom Betriebssystem in Form 
einer "Basiszugriffsmethode" bereitgestellt (vgl. z. B. /3/). 


‚Die Inanspruchnahme von Leistungen des Betriebssystems für die 
DFV ist ähnlich kompliziert wie bei der Nutzung der Unterstüt- 
zung des MMD unter den Bedingungen der lokalen Datenverarbei- 
tung. 


Für die Nutzung der Serviceleistungen des Betriebssystens be- 
treffs der Leitungssteuerung sind ein umfangreiches Detailwis- 
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sen und ein hoher Entwicklungsaufwand erforderlich. Aus diesen 
Gründen ist diese Form der Standardsoftwareunterstützung unnmit- 
telbar für die Anwendung des MMD zur Rationalisierung von Daten- 
verarbeitungsaufgaben nicht geeimet. Hinzu kommt, daß unter 
diesen Bedingungen die notwendige Software für die mittlere und 
oberste Schicht eines Dialogprogramnsystems ebenfalls entwik- 
kolt werden muß. 


3. Unterstützung der Anwendung des MMD durch komplexe Modul- 
systeme 


Komplexes Modulsysteme für die Realisierung des MMD basieren auf 
den Standardleistungen des Betriebssystems. Für ihren Leistungs- 
unfang ist aber charakteristisch, daß neben der Leitungssteue- 
rung auch die Nachrichtensteuwsrung unterstützt wird. Die Pro- 
grame für die Nachrichtensteuerung beinhalten solche Funktionen 
wie 

- die Initialisierung der Dialogverarbeitung am Terminal; 

- die Steuerung des Datenaustauschses zwischen dem Problempro- 
gramm und dem adressierten Terminal; 

- die Protokollierung und Behandlung von Fehlern, die vom Be- 
triebssysten bei der Datenübertragung zwischen einem Terminal 
und der Zentraleinheit der EDVA erkannt wurden; 

- die Vermeidung der Beeinflussung eines gestörten Terminals 
auf oränungsgemäß arbeitende Terminals (so darf z. B. die Ab- 
schaltung eines gestörten Terminals die Arbeit an den anderen 
aktiven Terminals nicht behindern); 

-— die Realisierung von Rechnerzeitzweisungsprinzipien für die 
Nachrichtenverarbeitungsprogramme (Problemprogramne). 


Die Nachrichtenverarbeitung wird in der Regel in den Problenm- 
programmen realisiert. Während die problemspezifische Nachrich- 
tenverarbeitung ausschließlich in den Problemprogrammen er- 
folgt, sind Softwarekomponenten der Nachrichtenverarbeitung, 
die für die multivalente Nachnutzung geeignet sind, häufig 
ebenfalls Bestandteile von den. Modulen der Dialogverarbeitung. 
So sind in diesen Modulen oft folgende Funktionen der Nachrich- 
tenverarbeitung realisiert: 
-— Realisierung von Komponenten des SPOOL-Prinzips (z. B. für 
Lese- und Schreiboperationen werden keine mechanischen Ein- 
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und Ausgabegeräte unmittelbar verwendet, sondern nur externe 
Speicher, die einen schnellen Zugriff gestatten). 

-— Kommunikationsmöglichkeiten zwischen den Terminalnutzern un- 
tereinander und/oder zwischen ihnen und dem Operator an der 
EWA, 

- Steuerung der terminalbezogenen Protokollierung von Aus gabe- 
informationen Über den Systemädrucker der EWA, die der Nutzer 
am Terminal wahlweise abfordert. 

- Wahlweise Protokollierung der Terminalsitzung, wenn es der Nut- 
zer wünscht, in einer sogenannten LOG-Datei auf einem externen 
Speicher (diese Funktion ist notwendig, wenn die Gefahr eines 
Systemausfalls besteht und unter Umständen eine RESTART-Orga- 
nisation notwendig werden kann). 

- Steuerung der Kompatibilität zwischen den im Problemprograrm 
und in den Modulen für die Unterstützung der Anwendung der 
Dialogverarbeitung verwendeten Programiersprachen. 

- Unterstützung der Arbeit mit Direktzugriffsdateien im Nach- 
richtenverarbeitungsprogram. 


In einem Modulsystem für die Unterstützung der Diealogverarbeitung 
missen neben den Softwarekomponenten für die Leitungs- und Nach- 
richtensteuerung zusätzlich Leistungen enthalten sein, die das 
Arbeiten mit Dateien im Direktzugriff im Problemprogramn einfach 
gestalten. Die Anwendung des MMD für die Rationalisierung von 
Datenverarbeit ungsaufgaben ist ohne äle Möglichkeiten des Direkt- 
zugriffs zu den benötigten Dateien nicht akzeptabel, insbeson- 
dere zur Sicherung des angestrebten Antwortzeitverhaltens zwi- 
schen einem Nutzer und einem Rechnersystem. Die. Inanspruchnahme 
der Möglichkeiten des Direktzugriffs zu Dateien im Rahmen der 
konventionellen Programmiersprachen (z. B. in den Programnier- 
sprachen ASSENHLER oder PL/l) ist kompliziert, insbesondere wenn 
eine. Datei geladen werden soll. Aus diesem Grunde müssen zum 
Modulsystem für die Unterstützung der Dialogverarbeitung Pro- 
gramme gehören, die mittels der Makro- und/oder Prozedurtechnik 
für das Laden und/oder das Lesen und/oder das Rüockschreiben- von 
Datensätzen einfach im Problemprogramm zu nutzen sind. Außerdem 
sollte zum Modulsystem für die Unterstützung der Dialogverar- 
beitung ein Dateimanipulationssystem für die Wartung der Direkt- 
zugriffsdateien gehören. Dieses Dateimanipulationssystem muß 
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zumindest die "Update"-Funktionen (Insert- und/oder Replacement- 
und/oder Deletö-Funktion für einen Datensatz in einer Datei) und 
das Lesen einer Datei und/oder eines Datensatzes der Datei am 
Terminal ermöglichen, 


Komplexe Modulsysteme sind für die Unterstützung der Anwendung 
der Dialogverarbeitung bei der Rationalisierung geeigneter Daten- 
verarbeitungsaufgaben nutzbar und Sollten vorrangig dann Ange- 
wendet werden, wenn abarbeitungsboreite Standard-Programnsysteme 
der Dialogverarbeitung für das eingesetzte Rechnersystem nicht 
verfügbar sind. Aber auch beim Vorhandensein der nachfolgenden 
Bedingungen ist der Einsatz komplexer. Modulsysteme akzeptabelt 

- die Anwendung des NMD erfolgt nur durch solche Nutzer, die 
nicht programmieren wollen (Dialogcompiler und -interpreter 
werden von solchen Nutzern nicht benötigt); 

- die Anwendung des MND setzt keine Datenbank voraus; 

- üle zur Verfügung stehende Kapazität äes Hauptspeichers und 
der externen Speichermedien, die den schnellen und wahlfreien 
Zugriff gestatten, ist begrenzt; 

- die Rationalisierung des Modulsystems soll unter der Verantwor- 
tung des Nutzers möglich sein (es ist schwierig, in die Pro- 
gramnstruktur abarbeitüungsbereiter Standard-Programsysteme 
der Dialogverarbeitung einzudringen); 

- Gle Anwendung des AMD erfolgt nur im Teilhaberbetrieb; 

- das Testen der Problemprogramme erfolgt nur im Stapelbetrieb, 


4, Abarbeitungsbereite Standardprogrammsysteme der Dialog- 


verarbeitung j 
Diese Programmsysteme unterstützen die Leitungs- und Nachrichten- 
steuerung sowohl unter den Bedingungen der lokalen Datenverarbei- 
tung als auch unter den Bedingungen der Datenfernverarbeitung 
umfassender als komplexe Modulsysteme und enthalten auch für die 
Nachrichtenverarbeitung unfangreichere Softwarekomponenten, Der 
Leistungsumfang dieser Programnmsysteme kann nach ihrer Generie- 
rung beim Anwender ohne Programmieraufwand sofort genutzt werden. 
Es ist aber erkennbar, daß die Standard-Progrannsystemo, die 
gegenwärtig angeboten werden, für die Nachrichtenverarbeitung 
vorrangig nur multivalent einsetzbare Problemprogramme enthal- 
ten, 2. B» Editorsysteme, mehrere Compiler, Syntaxprüfer und 
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Programmgeneratoren für die Unterstützung der Entwicklung von 
problemspezifischer Software. Die Erstellung der problemspe2zifi- 
schen Programnsystems geschieht vorrangig unter der Verantwor- 
tung des Nutzers (z. B. durch Eigenprojektierung und/oder Kauf). 


Abarbeitungsbereite Standard-Programnsysteme können als Teil- 
nehmer- und/oder Teilhabersysteme genutzt werden. Während Teil- 
nehmersysteme insbesondere die Arbeit mit Dateien unterstützen, 
sind Teilhabersysteme entweder vorrangig für die Arbeit mit Da- 
teien oder für die Arbeit mit einer Datenbank ausgelegt. 


Die Leistungen einss abarbeitungsbereilten Standard-Programn- 
systems werden durch eine Kommandosprache und/oder Makros bzw. 
Prozeduren in. den problemspezifischen Programmen in Anspruch 
genommen. 


Abarbeitungsbereite Standard-Programme sind vor allem dann zu 
nutzen, wenn folgende grundsätzliche Bedingungen für die Ratio- 
nalisierung von Datenverarbeitungsaufgaben vorliegens 

- umfangreiche Serviceleistungen der Dialogverarbeitung für die 
Erarbeitung von Problemprogrammen sind erforderlich (z. B. 
wenn viele Problemprogramme zu erarbeiten sind); 

- dis umfassende Nutzung: der Unterstützung des Betriebssystens 
für die Arbeit mit Dateien ist am Terminal notwendig; 

- der Einsatz einer Datenbank ist geplant bzw. bereits unter 
Bedingungen der Stapelverarbeitung realisiert; 

- die Probleme des Nangels an Hauptspeicher- und externer Spei- 
cherkapazität sowie der Realisierung einer hohen Operatlions- 
geschwindigkeit bei dem genutzten Rechnersystem sind weitest- 
gehend irrelevant; 

-— die Anwendung des NMD ist in Teilnehmer- und Teilhabersystemen 
vorgesehen; 

- die Anwendung des MMD ist für viele unterschiedliche Nutzer 
mit sehr differenziertem Aufgabenspektrum konzipiert; 

- die Anwendung des MMD wird sowohl unter den Bedingungen der 
lokalen DV als äuch der DFV realisiert. 


Die unmittelbare Anwendung abarbeitungsbereiter Standard-Pw - 
grammsysteme für die Realisierung des NMD erfordert gegenwärtig 
umfassende Kenntnisse vom benutzten Betriebssystem und zum Teil. 
detaillierte Programmierkenntnisse. Aus dlesem Grunde sollte 
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bei der Nutzung von abarbeitungsbereiten Standard-Programn- 
systemen für den YMD die Programmierung (einschließlich Test) 
der benötigten Problemprogramme von Spezialisten der DV durch- 
geführt werden. 
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Anwendung des Mensch-Maschine-Dialoges für betriebwirtschaftliche 
Aufgaben 


Vorbemerkungen - Standpunkt 


In hochindustrialisierten L&ändern wird der Anwendung des Mensch- 
Maschine-Dialoges als einer Betriebsform der Nutzung elektroni- 
scher Rechentechnik viel Aufmerksamkeit gewidmet, Immer neue An- 
wendungsgebiete werden für den Mensch-Maschine-Dialog erschlossen, 
Diesen Trend verdeutlicht nachstehende Gegenüberstellung,. 


Betriebsform 1971 198 1985/1990 
Stapelbetrieb 97 57 26 
Dialogbetrieb 3 43 74 


Verhältnis von Stapel- zu Dialogbetriseb in der Anwen- 
dung (Angaben in Prozent) nach: /6/ 


Diese Entwicklung mıß bei der Projektierung von DV-Systemen stär- 
ker als bisher beachtet werden, wobei zwei Tendenzen aus be- 
triebswirtschaftlicher Sicht besonders hervorzuheben sind3 
1, Der Betriebswirtschaftler mıß weit mehr als bisher die Daten- 
verarbeitungsprojektierung direkt beeinflussen und die Gestäal- 
tung interaktiver Systeme inspirieren, 
Besonders notwendig ist die intensivare Arbeit des Betriebs- 
wirtschaftlers in der Datenverarbeitungspro jektierungs-Phase 
"Systementwurf", um bereits hier die wichtigsten Komponenten 
seines Fachgebistes berücksichtigen zu können und um häufig 
auftretende Fehler auszuschalten. Dabei darf er sich nicht 
auf die Einflußnehme auf das Organisationsprojekt beschränken, 
2. Der Betriebewirtschaftler muß die Dialogführung im Rahmen in- 
teraktiver Systeme in die Lösung seiner täglichen Arbeitsauf- 
gaben integrieren, 
In fortgeschrittenen Betrieben und Kombinaten werden mit Hilfe 
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des Mensch-Maschine-Dialoges bereits zahlreiche betriebswirt- 
schaftliche Arbeitsaufgaben rationalisiert, Als Beispiele 
seien genannt: die Materialdispomition, die Materialbestands- 
führung, die kurzfristige Planung, Lenkung und Kontrolle der 
Produktion, die Kontenführung im Kontokorrent, die Terminkon- 
trolle, die Absatztätigkeit. 

Zu berücksichtigen ist in diesem Zusammenhang, daß betriebs- 
wirtschaftliche (informationelle) Prozesse elementarisiert 
werden müssen, um automatisierungsmlirdige Tellaufgaben fest- 
zustellen und aus diesen die dialogwürdigen zu bestimmen. Die- 
se Elementarisierung sowie die Algorithmierung automatisle- 
rungswürdiger Prozesse als eine Grundvoraussetzung zu ihrer 
Automatislerung erfordert hohen Aufwand an lebendiger Arbeit 
und kann nur in relativ langen Zeiträumen realisiert werden. 


Arbeitsteilung zwischen Mensch und Automat 
Beiri Mensch-Maschine-Dialog können den Automaten und den Men- 


‚schen, entsprechend den Fähigkeiten der Dialogpartner die je- 


weils am effektivsten zu lösenden Aufgaben Übertragen werden. 

Diese Arbeitsteilung zwischen Mensch und Automat ermöglicht we- 
sentlich höhere Rationalisierungseffekte, als sie bei ‘konventio- 
neller Stapelverarbeitung zu erreichen sind. Um diese höhere Ra- 


tionalisierungseffekte realisieren zu können, ist-unter anderem 
auf folgende Grundüiberlegungen zu achten: 


- Die Arbeitsgeschwindigkeit des Dialogpartners - Mensch - ist 
im Verhältnis zur Arbeitsgeschwindigkeit des Dialogpartners 

- Automat - gering. 

Der Dialogpartner - Automat - ist in der Lage, mit einer grö- 
'Beren Anzahl von Dialogpartnern - Mensch - unterschiedliche 
oder gleiche Probleme zur gleichen Zeit zu bearbeiten. 

Die Fertigkeiten und Fähigkeiten sowie der Kenntnisstand des 
Dialogpartners - Mensch - sind sehr unterschiedlich und nur 
relativ langfristig veränderbar. 

Die Sprache des Dialogpartners - Mensch - ist nicht eindeutig, 


Das Verhalten des Dialogpartners - Mensch - ist nicht immer 
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streng rational und oft von physischen und psychischen Ein- 
flüssen geprägt sowie von der Umwelt abhängig. 

- Die Reaktionsfählgkeit des Dialogpartners - Mensch - ist der 
Reaktionsfählgkelt des Dialogpartners - Automat - unterlegen. 

- Oft besitzen die Endnutzer in betriebswirtschaftlichen Fach-- 
bereichen Vorbehalte oder Vorurteile gegenüber der elektroni- 
schen Rechentechnik, 

- Die Fähigkeiten des Dialogpartners - Mensch - sind gegenüber 
dem Dialogpartner - Automat - vor allem im Bereich der Infor- 
mationsspeicherung und im numerischen Bereich wenig ‚entwickelt. 

- Im Urteilsvermögen und im assoziativen Denken, im Entwickeln 
von Initiativen und im Erkennen von Zusammenhängen ist der 
Dialogpartner - Mensch -— dem Dialogpartner - Automat - weit 
überlegen, 

- Der Dialogpartner - Automat --- kann.die Arbeitsweise des Dia-.- 
logpartners - Mensch - in bezug auf ihre Exaktheit unmittelbar 
kontrollieren, 

- Der Dialogpartner - Automat - ist dem Dialogpartner - Mensch - 
in bezug auf Dauerbelastbarkeit in einem interaktiven System 
überlegen. 


Bei Beachtung dieser Grundiberlegungen ergibt sich eine logische 

Arbeitsteilung im Mensch-Maschine-Dialog. 

So sind beispielsweise routinemäßige, arithmetische und logische 

Operationen sowie die Informationsspeicherung dem Automaten zu- 

zuordnen. Die Ansprliche an den Dialogpartner - Mensch - sind ge- 

ring zu halten hinsichtlich 

- Sprache (zu orientieren ist auf dieUmgangssprache sowie die 
entsprechenden Fachtermini einschließlich einer einfachen Kom- 
mandosprache) 

- Fertigkeiten und Fähigkeiten (zu orientieren ist beisplelwwel- 
se auf eine einfache Bedienung der Dialoggeräte am Arbeits- 
platz) 

- Rationalität (beispielsweise muß unlogisches Denken und unmo- 

tiviertes Handeln des Dialogpartners' - Mensch - berlicksichtigt 

werden) 

Kenntnisstand (zu berücksichtigen ist der Kenntnisstand von 
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AnfEngern und von Fortgeschrittenen,. z. B. durch Anwendung der 
Menlitechnik), 


Damit sind grundlegende Aufgaben bei der Projektierung interakti- 
ver Systeme verbunden, deren Erfüllung nicht vernachlässigt wer- 
den darf, Diss gilt insbesondere für Datenverarbeitungsprojekte 
des MenschrMaschine-Dialoges zur Lösung betriebswirtschaftlicher 
Aufgaben, 


Betriebwirtschaftliche Aufgaben sind unter anderem gekennzeich- 

net durch folgende Aspekte; 

1. Sia erfordern meist große Datenbestände, um die jeweiligen 
Aufgeben lösen zu können, 2. B. Daten aus dem Produktionspro- 
zeß, aus dem Bereich der Materialwirtschaft, aus dem Gebiet 
der Lohnrachnung oder aus dem Gebiet der Grundmittelrechnung,. 

2, Arithmetische und logische Operationen treten massenhaft auf. 
Arithmetische Operationen sind jedoch Im wesentlichen auf die 
vier Grundrechenarten besahrlinkt, 

3. Die Sprache des Betriebswirtschaftlere ist wenig eindeutig, 
Pntersuchungen der Zentralstelle für Primärdokumentation. in 
Zusammenarbeit mit der Technischen Univereität Dresden haben 
Zu B. ergaben, daß im Bereich der Fertigungsorganisation für 
etwa 100 Informationen 1100 unterschiedliche Begriffe verwan- 
dat werden, Die theoretischen Erkenntnisse der "Fuzzi set" 
dürften hier ein breites Anwendungsgebiet finden können, 

4. Die notwendigen Antwortzeiten bel betrlebswirtschaftlichen 

Aufgaben zeigen eine außerordentlich große Breite, Sie liegen 

im Bereich von wenigen Sakunden bis zu mehreren Stunden, ggf. 

reichen sogar Antwortzeiten von einigen Tagen, 

Vlela betrlobewiytschaftliche Aufgaben sind eingabe- und aus- 

gabeintenslv, 


Effekte sind aus betriebswirtschaftlicher Sicht: 

" Die Möglichkeit der sofortigen Verarbeitung eingegebener Infor- 
mationen führt zur Erhöhung der Aktualität gespelaherter Infor- 
mationen sowla von Verarbeltungsergabniasen, 

- Kartelen, Drucklisaten und andere Aufzeichnungen auf Papier am 
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Arbeitsplatz des Betriebswirtschaftlers können entfallen und 
lebendige Arbeit sowie Papier eingespart werden, 

- Die Möglichkeit der sofortigen Kontrolle eingegebeaner. Informa- 
tionen in bezug auf Plausibilität und syntaktische Fehler führt 
zur Reduktion von .fehlerhaften Rechnerläufen. 

- Durch die Verlagerung der technischen Mittel zur Informations- 
verarbeitung in die Fachbereiche erfolgt eine Integration die- 
ser Mittel in die an den Verarbeitungsergebnissen unmittelbar 
interessierten Struktureinheiten, Daraus resultieren unter an- 
derem eine Erhöhung der Qualität der Arbeltsaufgaben im Fachbe- 
reich, eine Aktivierung der Nutzer der technischen Mittel im 
Fachbereich, eine Erhöhung der Zuverlässigkeit der Informa- 
tionsverarbeitungsergebnisse, 


Organisationslösungen bei Einsatz des Mensch-Maschine-Dialoges 
in der betrieblichen Materialwirtschaft 


Aus den Aufgaben der betrieblichen Naterialwirtschaft können nach 
bisher vorliegenden Konzeptionen und praktischen Erfahrungen zwei 
Komplexe genannt werden, die einer Dialogführung mit Hilfe- von 
Bildschirmsystemen zugänglich sind und zugleioh der Dialogfüh- 
rung bedürfen, Das sind- 
i. aus dem Komplex Wareneingengs- und Lieferkontrolle, Vertrags- 
erfüllungskontrolles das operative Beschaffen von Material 
(im Sinne von Recherchen nach potentiellen Lieferanten) sowie 
das operative Mahnen von Bestellungenz 
2. aus dem Komplex Bestandsführung und Disposition: das operati- 
ve Freimachen von Material /vgl. 5/. 


Die Einbeziehung des Mensch-Maschine-Dialoges in Organisation» 
lösungen zur Rationalisierung der betrieblichen Materialwirt- 
schaft erfordert unter anderem eine neue Dateikonzeption. In 
einem ersten Schritt ist eine geeignete Echtzeitdatei zu schaf- 
fen. In bestimmten Anwendungsfällen wird darüber hinaus eine zu- 
sätzliche Datei notwendig, die eine ungestörte Erfassung von Wa- 
reneingängen während der Warenbewegung vom Wareneingang über die 
Wareneingangskontrolle bis zur Materialeinlagerung ermöglicht, 
Eine solche Organisationsform ist erforderlich bei mehrfachen 
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Wareneingängen zu einer Naterialart im Zeitintervall zwischen 
Wareneingang und Lagerilbernahme, Diese "Echtzeitdatel” ist nur 
über die erstgenannte Echtzeitdatel ansprechbar und enthält bei 
Bedarf für die entsprechende Materialart der Echtzeitdatel 1 die 
notwendigen Erweiterungssätze. ’ 

Auf der Basis vorgenannter Dateikonzeption wurde in einem Anwen- 

dungsbetrieb der Mensch-Maschine-Dialog realisiert. Folgende 

Effekte wurden z. B. erzielt: 

- Die Bereitstellung des Materials für Dispositionszwecke konnte 
etwa 10 Tage früher erfolgen als ohne Mensch-Maschine-Dialog. 

- Der Mensch-Maschine-Dialog mit den Echtzeitdateien ermöglicht 
eine tägliche Bestandsfortschreibung. 

- Operative Materialentnahmen können mit Hilfe des Mensch-Ma- 
schine-Dialoges sofort bestandswirksam gebucht werden, 

- Die tägliche bestandswirksame Erfassung der Wareneingänge/Le- 
gerübernahmen mit Hilfe des Mensch-Maschine-Dialoges ermög- 
lichte eine 75%ige Arbeitszeiteinsparung bei den im Datener- 
fassungsprozeß beschäftigten Arbeitskräften. 

- 123000 Lochkarten und 16000 m Papier werden jährlich einge- 
spart. 

- Die Rückflußdauer für das Wareneingangs-/Lagertibernahme pro- 
jekt beträgt weniger als 2,5 Jahre, 


Organisationslösungen bei Einsatz des Mensch-Maschine-Dialoges 
zur kurzfristigen Plenung, Lenkung und Kontrolle der Produktion 


Die kurzfristige Planung, Lenkung und Kontrolle der Produktion 
ist ein sehr interessantes Anwendungsgebiet für den Mensch-Ma- 
schine-Dialog. Zahlreiche Industriebetriebe haben entsprechende 
DV-Projekte bereits realisiert, andere befinden sich in der Pha- 
se der Projektierung. Aus den Erfahrungen eines führenden Anwen- 
ders lassen sich folgende Aussagen abheben /vgl. 9, S. 15/16/: 
Auf der Basis von fünf Bildschirmanwendungsprogrammen zur Nut- 
zung von Echtzeitdateien (Dialogdatelen) können folgende Infor- 
mationen auf den Bildschirm bereitgestellt werden: 
- Informationen zum Fertigungsauftrag, z. B. Stand der Bearbei- 
tung, Anzahl der Arbeitsgänge, Stand der Materialdeckung; 
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- Informationen über in Bearbeitung befindliche Fertigungsauf- 
träge;. 

- Informationen zum Anarbeitungsstand eines Auftrages insgesamt 
bzw. nach Fertigungsbereichen, 

"Weiterhin ist die tägliche Datenerfassung der Materialdeckungs- 

meldung am Bildschirm möglich, Sie zieht eine sofortige Aktua- 

lisierung aller Dialogdateien nach sich" /9, S. 17/. 


Demit wurden z. B. folgende Effekte erzielt: 

- sofortige Aktualislerung des Standes der materialgedeckten 
Fertigungsaufträge 

- Ausdehnung des Zeitraumes für die Datenerfassung, um mit ak- 
tuellsten Informationen zentrale Rechnerläufe durchführen zu 
können. 

- Erfassung der Materialdeckung dürch aen Nutzer im Fachbereich 
mit sofortiger Fehlerprüfung 

- Erhöhung der Aktualität ausgedruckter Informationen 

- Prüfung nach materialgedeckten_Aufträgen gleichzeitig durch 
verschiedene betriebswirtschaftliche Fachbereiche, 


Die Konzeption zur Welterentwicklung der bisherigen Organisa- 

tionslösung sieht unter anderem vor: 

1. automatisierte Abforderung von Fertigungsbelegen über Bild- 
schirm 

2. Ausweis der Bestände der Zwischenlager in einer Bildschirm- 
euftragsdatel 

3. Automatisierung der Auftragszuweisung als eine Aufgabe der 
zentralen Fertigungslenkung. 


Organisationslösungen bei Einsatz des Mensch-Maschine-Dialoges 
im Bereich Absatz 


Von den im Fachbereich Absatz in Betrieben und Kombinaten der 
Textilindustrie zu lösenden Aufgaben können ‚nach bisherigen Un- 
tersuchungen vor allem die Verkaufshandlungen-und die Kontrollen 
der Verträge durch den Einsatz von Mensch-Maschine-Dialogen ra- 
tioneller und effektiver gestaltet werden. 
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Speziell für Erzeugnisse, die mode- und saisonbedingten Schwan- 
kungen unterliegen, lassen Bich durch dialoggeführte Verkaufs- 
handlungen Ökonomische Effekte erzielen. Da für diese Erzeugnis- 
se der Bedarf qualitativ und quantitativ nur sehr grob einzu- 
schätzen ist, treten während der Verkaufshandlungen Abweichungen 
zwischen dem angebotenen Produktionssortiment und den Forderun- 
gen der Käufer auf. 

Während der Verkaufshandlüngen sind innerhalb einer kurzen Zeit- 

spanne zur Herbeiführung einer annähernden Interessenidentität 

zwischen Produzent und Käufer (Großhandel, Warenhäuser) Entschei- 
dungen zu treffen, die die Kenntnis einer großen Informations- 
menge voraussetzt. 

Bei der Entscheidungsfindung ist zu berücksichtigen, daß die For- 

derungen der Käufer realisierungsseitig abgesichert sind und den 

ökonomischen Kennziffern der Betriebe und Kombinate nicht entge- 
genwirken, Die Unterstitzung dieses Prozesses durch die Nutzung 
des Mensch-Maschine-Dialoges setzt u. a, eine Datenbasis mit fol- 
gendem Inhalt voraus: 

- Informationen Über die verfügbaren Fonds an Maschinenzeit je 
Maschinengruppe, an Arbeitszeit je Arbeitsgeng und an Material 
je Materialart, untergliedert nach Zeiträumen 

- Normative je Erzeugnis für Maschinenzeit, Arbeitszeit und Ma- 
terial je Zeitraum 

- Ökonomische Kennziffern des betrieblichen Reproduktionsprozes- 
898. 

Folgende Effekte lassen sich für 0. g. Aufgabengebiet durch den 

Mensch-Maschine-Dialog erzielen: 

Abschluß von Verträgen, die. den betrieblichen Ressourcen nicht 

widersprechen 

permanente Übersicht über verkaufsfreie Mengen je Erzeugnis 

und Liefertermin 

- Verringerung des Datenerfassungsaufwandes durch Vermeidung von 
Doppelerfassung der Information durch den Betrieb und die wirt- 
schaftsleitenden Organe 

- tagfortige Vertragsabschlußkontrolle, 
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Kollär, Lubor 


The Large Data Sets Processing Nathematical Software 


Abstract 

Most of widely used mathematical software systens are 
based on the subprogramming structure, where processing data 
are managed as parameters of a subroutine. Using-.the large data 
sets (the internal storage is not large enough to store them), 
some other conceptioöns- are needed. We prefere the use of 
the separate program modules connected only through external 
files because of the following advantages: the block concept can 
be well used; the variety of programming languages may be used 
in, building and using such a system without problems in 
different handling of parameters - only the data representation 
must -be in accord; standard file utilities can be easily used. 
The paper is devoted to some aspect of developement and 
implementation of the approach mentioned above, 
1. Introduction 

Our objective in this paper is to provide the brief 
discussion on constructing the large data sets processing 
mathematical software (LDS software). This software seems to be 
rather extensive, complex, atractive and useful piece of 
the progran equipment. Some specific problems of developement 
of this system are mentioned. We will describe the module 
conception used to construct this software. 

In section 2 the term LDS is explained and components of 
LDS software are defined. Some methods used in LDS software 
developement are presented in section 3. Section 4 contains 


a discussion on the adaptability and implementation problens. 


2. Modules and Data 
2.1. Large data Sets. 


Large data set (LDS) is a collection of large amount of 
data. But what does this "large amount" mean? Thousand or 
million numbers? In most cases more proper determination is: LDS 
is so large collection of data that the internal storage is not 
able to store it. It is clear that this definition is not exact, 
too; following facts must be taken into account when identifying 


given data set: 

i) computer and its operating system, 

ii) mode of coding and data representation, 

iii) problem to be solved. 
While the machine sets the physical limit on the maximum amount 
of data stored, the operating system gives the logical (and more 
realistic) one. Using special codings, structures and types of 
data representation the originally LDS may become not to be LDS 
one. hen solving some problems several data Sets are asked to 
be resident in the core simultaneously and this may be impossi- 
ble in spite of the possibility to store each of them separately. 
The most frequent types of mathematical objects represen- 

ted by LDs-s are matrices (mostly the sparse ones), vectors and 
errays generally. Trees, queues and other structures can also 
appear. 


2.2. Components of the LDS software 


There are two types of components which must be contenpla- 

ted in constructing and using the LDS software: 
i) program modules (software), 
and ii) .data files allocated outside the modules. 

The program module is a separate part of a progran code 
which communicates with other modules only by means of files. 
A subroutine, a program or a part of a program code can be 
a program module. The data file is a product of the module ’s 
activity. In contrast to the module, file is a dynamic component. 
LDS-s are data files, but also when it is useful to split up 
the module, some new "communication" data files are required to 
provide the connection, 

It is advantageous to classify the relations between 
modules and files by using three classes: 

i) creation a new file on the basis of given 
parameters or as a product of computations, 
ii) use of a file as an input for the. following 
computations, 
iii) file management, i.e. copying, data structure 
exchanging, providing of explicitely given 
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modifications of some values etc. 
Examples. 

Counting the determinant, matrix is an input file (ii) and 
the result can be printed, displayed or stored into a communica- 
tion file (i). The module, which solves a system of linear 
equations uses the matrix of the system and the vector of rizht 
sides values as the input (ii) and the resulting vector as 
the output (i). Exchanging the row=-oriented code of given matrix 
to column-oriented one with possibility of keeping both files is 
the file managing process (iii). 


3. LDS software developement 
3.1. Tools and techniques 


We shall point out some useful tools and techniques 
specific in developing the LDS software. 

Since most data structures used in LDS package are fairly 
complicated, it is helpful to have modules which will give 
various information about the data in intelligible form. For 
example, one may ask for a zero-nonzero structure of a sparse 
matrix stored in packed form or for a structure of a given tree. 

Other useful tools are structure debugging modules. They 
are used to test as much as possible whether the data contained 
in a storage structure is valid. To track down an error, 
a debugging module is inserted in strategic points of the erro- 
neous module and this expnded program is then re-run, 

Largeness of data causes some difficulties in testing. 
Auxiliary modules producing the test. problems are desirable, 
The test sets chosen or generated from widely different real 
applications are prefered. 

A lot of methods of storing the same data set are usually 
possible. For example, sparse matrix can be coded in many ways 
(see 4). There are several manners to handle this variability: 

i) construction of more modules for the same activity on 

different structures 

ii) building modules independent on the structure 

iii) using modules for exchanging the data structures as 
much as possible 
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The first possibility can rapidly increase the number of 
modules. For example, having three types of matrix structures, 
nine modules for matrix multiplication must be constructed. 
The second way is disadvantageous because of two main reasons: 
adding a new type of coding requires exchanges in more modules; 
the same "structure handling” program code will be present in 
multiple modules. So we prefere the third way. However, 
the preference is not strict. In some cases (e.g. solving 
a system of linear equations) construction of more structure 
dependent modules is desirable, because of the strong dependence 
of the complexity of some algorithms on data structures. Except 
of the specific tools a lot of general techniques exist. They 
are briefly described in 72]. 


3.2. Advantages 


The great independence of modules is helpful in many ways. 

The project can be divided into smaller units and the 
interaction between them minimized. Just this kind of division 
is the very best one according to [1]. 

Modules producing the test data as it was mentioned before 
enable to test the programs separately. This can rapidly save 
the time: when a chain of modules is constructed, anything can 
be tested without need of debugging of all previous modules. 

The variety of programming languages may be used in 
constructing such a software without problems in different 
handling of parametrs - only the data representation must be 
in accord. 


4. Adaptability and portability 


4.1. Extension and contraction 


The construction of an application software systen 
conforring to all user’s need is out of the question. Some 
modules are often inapplicable and some of them are frequently 
absent to satisfy the user's desire, 

The contraction is the first stage of software adaption in 
which user picks out all suitable modules. The portion must be 
compact or it must consist of compact parts. This requirenment 
can be easily fulfilled because of its great modularity. 


312 


Usually, the user wants to add some own modules or adapt 
the original ones to suit the system according to his object. 
When the addition suffices, only the data structures and 
representations are of interest to the user. The extension can 
be more simple if the debugging modules and other tools 
mentioned before are used. 

The problem of extension and contraction is not specific 
only for applicated software, but for the software generally 
(see [3]). 


4.2. Implemehtation 


Implementation is a really serious problem in the LDS 
software. A lot of modules claim much time and large storage to 
run, therefore it is necessary to adapt them precisely to given 
‘computer. Also operating system dependence is great. These 
facts cause the implementation is more laborious than usually. 
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Mikulecky, Peter - Kelemen, Jozef 


Supervising Expert Systems: 


An Attempt to Organize Certain Mathematical Software Intelligently 


Abstract 


The paper is devoted to some aspects of the design and orga- 
nization of mathematical software. An analysis of the possibility 
of using some recent results and ideas developed in the area of 
Artificial Intelligence (especially in the connection with the re- 
presentation of knowledge) is sketched, and a new type of expert 
systems -- supervising expert systems -- is suggested. These are 
based on the ideas of the frame representation of knowledge, deve- 
loped by Minsky, and implemented in FRL [Frame Representing Langu- 
age]. The final part of the paper is devoted to some considerati- 
ons on exploitations of the Minsky”s ideas concerning so called 
K-theory of memory in’ the design of "intelligent" software systems 
for solving problems in applied mathematics. 


Mephistopheles: 


Wen wiLL was Lebendigs erkennen und beschreiben, 
Sucht erst den Geist herauszutreiben, 
Dann hat en die Teile in seiner Hand, 
Fehlt Leiden ! nur. das geistige Band, 


J.W.Goethe Faust, I, Studferzimmer 


1. Introduction 


Recently, a new programming technology has been developed. co- 
ncerning the problem of transferring human expertise in given do- 
mains into effective machine form. A lot of so-called expert sys- 
tems have been implemented, enabling computer systems to perform 
convincingly as advisory consultants. According to the characte- 
risation given in [10], expert systems are program systems that 
are able to solve or to advise how to solve some substantial pro- 
blems generally conceded as being difficult and requiring exper- 
tise. Expert systems are called knowledge based because their per- 
formance depends critically on the use of facts and heuristics u- 
sed by experts. 

Expert systems are seemed to be very useful tool for relati- 
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vely unskilled specialists or non-specialists in-given domains. More- 
over, they have been used as a vehicle for Artificial Intelligence 
(AI) research in the direction of a very effective exploitation of 
the recent results on knowledge representation and the design of 
programming languages for AI. A deep characterization of expert sy- 
stems can be found in [5]. 

In the connection with the expert systems development we have 
turned our attention mainly on two ways of exploitation the AI re- 
search results 

(1} The tools established in the scope of the AI research for 
the representation of knowledge [e.g., the FRL programming 
language, see [9]} can be successfully used for unambiguous- 
ly interpretäable representation of nonalgorithmic knowledge. 
This can be illustrated by representation of knowledge in 
medical diagnostics,. n 

(2) The tools mentioned in (1) can be (perhaps after slight en- 
largement) used as tools of an "intelligent" integration of 
previously disconnected programming products. This way of u- 
sing the AI research results is in our opinion. very perspec- 
tive and deserves our main attention: all through ‘the paper. 


2. Supervising Expert Systems: 


A Motivation and Basic Considerations } 


A human expert is able to integrate in some "intelligent" way 
his partial abilities or knowledge into certain greater units. He 
is able not only to use the learned knowledge but also to establi- 
sh {relatively reliable) the circumstances under which what know- 
ledge is.useful and in what sense. The knowledge enabling it is u- 
sually called the meta-knouledge (see, e.g. [1]). -It is acceptable 
to state such approximation of the term "meta-knowledge" which ex- 
plaines it asa knowledge on the knowledge-base having in the sys- 
tem disposal. 

Without civing some extra reasons we can state that essential- 
ly all real "artificial" expert systems dispose with lat least im- 
plicitiy included) system of meta-knowledge. For instance, Barr in 


Ill pointed out that it is possible to view an interpreting prog- 
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ram in terms of knowledge about its data base, called meta-knowled- 
ge, because the interpreter must in some sense know the extent and 
limit of available knowledge, what facts are relevant in a given 
situation, how dependable they are, and how they are used. 

The "olassical"style of the design of expert systems is such, 
that the knowledge-base and the representation of necessary meta- 
knowledge are established in a mutual interaction (though, usually 
using different means). It is possible to adjust meta-knowledge to 
the specific features of the knowledge-base, and vice versa. This 
is very often exploited and it probably causes that to the time 
present it is very rarely a success appeared in separating some 
universal normatives for the expert systems design from the expe- 
riences with designing particular expert systens. 

We shall to emphasize the role of the meta-knowledge in ex- 
nert systems by introducing the notion of the supervising expert 
systems. These are based on the fact that recently (particularly 
in some areas of science, e.g., in the applied mathematics) there 
are accumulated a lot of mutually disconnected software products 
(le.9., whole libraries of application'programs for solution a vari- 
ety of problems in applied mathematics]. The knowledge of an user 
- expert in using such program packages is primarily not identical 
with the knowledge expressed in the programs of the package, but 
its contents mainly includes the effective way of the exploitati- 
on of the package. It means; that in the relation to the contents 
of a program package the expert plays the role of an intelligent 
supervisor deciding when who what will perform. The knowledge u- 
sed by an expert in such activity has in the relation to the know- 
ledge embedded in the programs of a package character of the meta- 
knowledge. The first goal to be achieved in the way towards arti- 
flcial supervising expert systems is the transfer of such knowled- 
ge into artificial systems [computers]. 

Let us shortly summarize the essence of the supervising ex- 
pert systems 

- to profit from the existing program packages without knowing 
in detail the structure of such package ör without necessity 
to construct new elements of the package; 

- to enable to a non-specialist using of program packages in ra- 
ther intelligent and qualified way in solving problems from 
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given domains; 

- to facilitate to a relatively unskilled specialist using of 
program packages with the goal to improve his skillness in sol- 
ving problems from given domains, 

In what follows we try to present some arguments on behalf the 
thesis that existing means of. AI are applicable in achieving this 


goal. 


3. Supervising Expert Systems : A Case Study 


In the previous section we have characterised in short what 
we understand under the supervising expert systems. For the sake 
"SE illustration we shall mention now several aspects of the nature 
of supervising expert systems. To be more concrete, we shall de- 
monstrate an example, how can be constructed a supervising expert 
system for the domain of applied mathematics, and what are the dif- 
ferences between supervising experts and experts in the common-sen- 
se meaning, 

Let us imagine the situation of a mathematician who is given 
a problem, say, to solve a boundary value problem for an elliptic 
partial differential equation. What has he to do ? 

First, the mathematician must to identify the type of the 
problem in the sense of its mathematical characterization. He is 
exploiting his knowledge on the domain resulting into the reali- 
“zation, that he is solving a boundary value probl&m for given el- 
liptic PDE. Then the mathematician takes into account what requi- 
rements have to be put on the solution of the problem, and again 
according to his knowledge he is choösing a method för solving’the 
given problem. It is obvious, that more skilled expert in the do- 
main has to his disposition a larger variety- of methods, while a 
layman hardly knows about one or two suitable methods. However, 
one feature can be shared by both of them they essentially need 
not know a lot of details about used methods, or about their im- 
plementations. An analogy with the knowledge of programming lan- 
guages is on hand a, user creating a program need not know how 
are the used instructions implemented, how are they realized in 
the computer in detail. But an implementer, or designer of the 


language must have.a deep knowledge in this direction. 
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Above mentioned feature can be considered as one of the main 
features of the supervising expert -ystems: they are able to per- 
form considerations and other activities like very skilled experts 
in the problem domain, who essentially know 

- what type of problem is to be solved, 

- what method is the best [according to the present circumstances] 

for this type of problens, 

- how are the principles of using the method, 

- whether or not the method is available, 
but they need not know how is such and such method detaily constr- 
ucted or implemented. That is, they can use the method as a "black 
box". 

Let us continue our considerations on the activity of an ex- 
pert - mathematician, who is given the problem of solving a boun- 
dary-value problem for an elliptic PDE. Now, he already knows the 
type of the problem, the requirements putting on the solution,and 
what methods are available on his computer. According to his skil- 
lness, he is inspecting his own knowledge or he is consulting so- 
me other specialists what method is the best for his problem, and 
suddenly, he is choosing the method and uses it. In the view of 
our considerations from”the previous chapter, the mathematician 
is supervising (more or less intelligently} when who and what will 
do And this is actually what we require the supervising expert 
systems will do 

Hence, a supervising expert system extends in a rather intel- 
ligent manner the abilities of an existing package of methods ne- 
cessary for solving the problems in a given problem domain. It is 
playing a role of a skilled expert in this domain, who is supervi- 
sing the employment of the methods from the program package, 

Following just mentioned basic ideas, a supervising expert 
system has been designed at the Comenius University in Bratislava 
(see [6], [11]) which would be able 

- to analyze and recognize given problems from the area of appli- 
ed mathematics (more concrete, the domain is: initial and boun- 
dary value problems for ordinary and partial differential egqu- 
ations]; 

- to make an expertise in suggesting the best suitable (and, of 
course, available) method for solving the problem; 
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- to choose the method from a (rather large) program package; 

- to arrange the application of the method, i.e., the computa- 
tion; 

- to evaluate the results and to correct eventual mistakes. 

Some basic ideas of the possibility of the construction of 
such system have been introduced in [3]. 

The supervising expert system is called ASPAM (The Advisor 
by Solving Problems from Applied Mathematics) and for the time 
being has not been implemented as a whole. A part of the system 
has been experimentally implemented in the FRL programming langu- 
age at ES-1010 computer as an illustration of the usability of 
the FRL language for such purposes.Further implementations are in 
the preparation at the ES-1033 and SM 4/20 computers. 

The system ASPAM can be very schematically visualised as fol- 
lows 


Supervisor - | FORTRAN 


The majority of above mentioned activities of the system 
are perförmed interactively in tight contact with the user. The 
user, according to his skillness 'enables to perform system”s ac- 
tivities in more or less leeway. There is a lot of types of dif- 
ferential equations represented in the supervising part of the sy- 
stem using their frame representation in the FRL, and the system 
matches the input against them and recognize the problem to be 
solved. As an example, let us write down the FRL representation 
of an ordinary differential equation, say, the first order line- 
ar ODE with the constant coefficients and with a right-hand si- 
de 
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C"(DEFRAME “LDE-RHS-CC=-1 
°(AKO (SVALUE (LDE-1))) 
"CRH=SIDE -($VALUE (CONST))) 
“(NEXT-MEMB ($VALUE (CONSTXY)) 
($VALUE (ZERO))))) 


The frame LDE-RHS-CC-1 is connected with the frame LDE-1 (which 
‘is higher in the hierarchy of.used frames] using the relation AKO 
(a kind of). The frame LDE-I1 represents all first order linear ODE”s. 
In the slots RH-SIDE and NEXT-MEMB are then the values of the rig- 
ht hand side of the equation, and the next member of the left-hand 
side (the member without the derivation of y), respectively. 

According to the modular construction of. the ASPAM system and 
the modularity of the FRL programming language, the expert system 
can be very easily enlarged by adding some other types of equations 
or initial- and boundary-value problems. 


4. Another Approach: Viewing Supervising Expert Systems 
As Collections of Communicating Agents 


In the last years in several professional circles of the AI- 
researchers an opinion has appeared according to which the way of 
the functional and structural approximation of the intelligence can 
be led through the understanding of intelligence as a performance 
of a collection of certain intercommunicating entities. 

Hewitt [2] presents, for example, an approach to modelling in- 
telligence in the terms of communicating knowledge-based experts, 
whereby each expert can be viewed as a society that can be further 
decomposed until the primitive actors of the system are reached. 

Yonezawa and Hewitt [12] state that the tools for representing 
the modular knowledge with procedural attachments (for example ‚Min- 
sky”s frames) can be modelled and implemented as actors,. 

While the approach just mentioned streams from the use of a 
new type of the computational paradigm, Minsky comes to the concept 
of the distributivity using a new psychologieal hypothests. In the 
sense Of this hypothesis (see, e.g., Minsky [8]) the mind is viewed 
as an organized society of intercommunicating agents. The ‘character 
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of this intercommunication is sketched in [7]. Primary Minsky”s in- 
tention is to establish such [computationaly formalizable) theory 
of the structure and function of the memory, in which besides "cla- 
ssical" questions of the type "How is the information represented?" 
or "How is it stored, retrieved, etc, interesting for those who 
are working in the area of AI, would be possible also effectively 
answer to more psychologically motivated questions of the type "How 
are tne abstraetions made ?", "How are they later instantiated ?", 
and so on. 

Minsky tries to envelop all these questions by establishing 
the thesis, that the function of a memory is to re-create the sta- 
te of the mind. The schema how this can be realized is formulated 
relatively simply 

" "nen you ®get an idea’, or ’solve a problem’, or have a ”’me- 
morable experience’, you create something we shall call a K-lines 
for it. \ ZT = 

This K-line gets connected to those ”mental agencies’ that 
vere recently active -- i,e., which were involved in. the memorable 
mental event, 

When the K-line is later ”’activated’, it reactivates those 
mental agencies, creating a ”’partial mental state’ resembling the 
original.” (Minsky [7]) 

It is obvious that this schema is only a starting formulation 
and requires further concretization before its implementation. Ne- 
vertheless, this fact cannot hinder us in considering the potenti- 
al possibility of an exploitation of the schema in the design of 
supervising expert systems. Our considerations can be, of course, 
only contemplative and their goal is not in.giving instructions to 
an activity, but only a proposition for further contemplations. 

Let us suppose now, that we intent to create again a supervi- 
sing expert system for applied mathematics, Every program from a 
program package or a library can be considered.as an agent. These 
agents (let us denote them Kı, „ee, Kn and call them K-agents) are 
then able to solve some particular problems which can appear in 
the area of applied mathematics le.g.,' a procedure for the numeri- 
cal quadrature is an agent, a procedure for the Runge-Kutta method 
of integration of an ODE can also be viewed as an agent, etc.].We 
need also agents which are able to find out the relevance of some 
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K; to the given problem. .Denote them P,,. es, En and call them 
the P-agents. They express certain meta-knowledge we have trea- 
ted in the Section 2. 

Another agents are necessary for finding out the acceptabili- 
ty of the results received by Kı, „ee, Kn. Denote them K!, „.., Kr 
These are also K-agents. 

Finally, the formulation of concrete goals of our expert sys- 
tem is made using a special type of agents G,4, oe.» 6.” the G- 
agents. 

Assume, that connections between agents are inserted into the 
expert system by human experts. These connections express primari- 
ly their meta-knowledge concerning the program-base over which the 
supervising expert system is constructed, There are several types 
of connections between agents. We shall call the connections bet- 
ween P-agents P-lines, between kK-agents and P-agents K-P-lines, 
and so on. 

Let us illustrate now the previous considerations. Let us sup- 
pose we are designing a supervising expert system for solving the 
initial-value problems for ODE”s of the first order, and in the 
program-base we have just two well-known numerical methods -- the 
Runge-Kutta method of the 2nd order, and the Hamming predictor-cor- 
rector method of the 4th order. It is rather. poor package, indeed, 
but for. the sake of illustration it is enough. Assume, that the 
system dispose with the following agents lin the parentheses the 
werbal specifications of functions of the agents are expressed]: 


Pı (in the given problem finds out the greatest derivation in 
the ODE} 

Pa. (finds out the existence and the form of the right-hand si- 
de of the ODE) 

Ps (finds out the given interval) 

Pa (finds ou+ the given integration step] 

Ps (finds out the form of the initial condition] 

Ps lestablishes the required precision of results] 

P7 lestablishes the required precision of the corrector in 
the Hamming”s method) 

Pe (using the results of the activity of subordinated agents 
Pıseoe, Pz establishes whether or not it is reasonable to 
solve given problem using the Runge-Kutta method} 
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Po (analogically establishes whether it is reasonable to use 
the Hamming”s method) 

Pıo (using messages from all subordinated P-agents establishes 
whether the given problem is to solve an ODE, i.e., whether 
or not the obtained data are relevant to the formulated pro- 
blem) 


The problem to be solved can be formulated using unique G-age- 
nt G,; which arranges connections between the data about the problem 
and the data about the result [the solution of the problem), and 
enables to specify the type of the problem. 

K-agents enabling the proper process of solution the given 
problem can be established as follows 


Kı (the procedure for the Runge-Kutta method of the 2nd order, 
which uses on its input the results of the perceptions of 
the agents Pı, „os, Pe mediated through Pe] 

K2 (tests the agreement of the result with required precision, 
as a result of the perception of Pe) 

Ka (the procedure for the Hamming”s predictor-corrector method 
of the 4th order, which needs in addition the result of the 
perception of Ps] 

Ka (arranges the output of obtained results] 


The connections between agents are schematically visualised 
on Fig.1l by arrows. The type of each connection can be derived 
from the type of its tail-agent and head-agent. When the connec- 
tion begins, for example, in the P-agent and ends in the K-agent, 
the type of this connection is P-K. It is worth to note, that we 
assume, that given agent can treat an information and to pass it 
to another agent only in the case all its inputs (of the same ty- 
pe] are saturated. The numbers assigned to the connections are the 
numbers of stages of the transfer of the information between agents 
(note, that the possibility of the parallelism can ke considered). 

In our considerations on the Minsky”s suggestion we have not 
dealt with the characterization of the information retrieving mo- 
de in the nets of agents. Note, that the mode of the information 
retrieval in our example is in accord with the Minsky”s suggesti- 
on [recall, .e.g., the clockwise spiral form of computation, stres- 
sed in [7}])]. 
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5. Conclusion 


Our intention in the paper was to characterize one relatively 
new type of expert systems -- the supervising expert system -- mai- 
nly by introducing two suggestions of concrete supervising expert 
systems construction for the purposes of solving problems in the a- 
rea of applied mathematics. 

We suppose, that a powerful tool for the realization of expert 
systems can be found among programming languages designed in the sco- 
pe of Artificial Intelligence. We have already some first experien- 
ce with using FRL for this purpose (compare [11], [6]). Note, that 
there exist already in the area of actor”s approach some suitable 
programming tools, for instance the languages PLASMA [2] or Act 1 
[4]. However, we still do not know about their using in the process 
of design of the expert systems. Alike we have no knowledge on the 
existence of a computer realization of the Minsky”s model, 

Nevertheless, we can suppose that just by the pragmätism influ- 
enced considerations on potential practical exploitation of these 
suggestions can done some motivations to the creation of a more pre- 
cise image of the requirements for concrete computer implementati- 


ons, 
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Konzeption eines Auswertungseystens für das Krankenhaus 
Friedrichshain von SKR-Rechentechnik 


Durch den immer größer werdenden Umfang der Nutzung von Daten- 
verarbeitunsstechnik im Krankenhaus ergeben sich weiterführen- 
de Fragen und Anforderungen. So steht inzwischen ein umfang- 
reicher Datenpool zur Verfügung, für den der Zugriff verhält- 
nismäßig schnell und zu jedem Zeitpunkt möglich ist. Es. er- 
gibt sich die Frazre nach’ Auswertung dieser vorhandenen Daten, 
Eine häufige Fragestellung betrifft die Anwendung statistischer 
Verfähren. Deshalb wird für das Krankenhaus Friedrichshain 

ein Auswertungssystem entwickelt, mit dem diese Fragen beant- 
wortet werden können. 


1 Ällgemeine Voraussetzungen 
Um hier sinnvolle Grenzen zwischen Möglichem und sinnvoll 


Durchführbarem zu finden, ist es notwendig, sich einerseits 
das Spektrum der häufig auftretenden Pragen anzusehen und 
andererseits die Voraussetzungen der künftigen Nutzer zu be- 
achten. Das Spektrum der Fragestellungen ist, wie in einem 
allgemeinen Krankenhaus zu erwarten, relativ breit gefächert. 
Um eine sinnvolle Größe des Auswertungssystems zu erhalten, 
muß hier zwischen häufig gebrauchten und sehr speziellen am 
Rande auftretenden Fragestellungen unterschieden werden. 

Als vernünftiger Rahmen erscheint hier die Beschränkung auf 
häufiger benötigte Verfahren, wobei jederzeit der: Anschluß 
spezieller Verfahren möglich ist. 

Da relativ einfache Fragestellungen oft auftreten, soll der 
Anwender seine Probleme über ein speziell dafür bereitgestell- 
tes Terminal soweit wie möglich. selbst lösen können. Da EDV- 
Kenntnisse nicht vorausgesetzt werden dürfen, muß dem Nutzer 
weitestzehend Hilfestellung gegeben werden. Das läßt sich 

am besten über Dialogsteuerung verwirklichen, 

So ergeben sich für das Auswertungssystem folgende Rahmen- 
bedingungen: Er 


- es ist für die Anwendung in einem größeren Krankenhaus 
gedacht, um mit Hilfe ‘eigener Kleinrechentechnik schnelle 
Auswertungen an Ort und Stelle zu ermöglichen. 


- 2? - 


327 


- Anwender, die häufigere Fragestellungen in dieser Richtung 
haben, sollen mit dem System an einem dafür vorgesehenen 
Terminal nach kurzer Einführunzszeit selbständig arbeiten 
können. 

- Der Umfang der anzebotenen Verfahren soll Überschaubar und 
für normalerweise häufig auftretende Probleme zugeschnitten 
sein. (Es soll also bei weitem nicht der Leistun:sumfang 
von z.B. PP-Statistik erreicht werden, Zumal es sich hier 
in diesem Fall um den Einsatz von Kleinreohentechnik handelt, 
dies soll und kann nicht Ziel für diese Änwendung sein.) 

- Der Nutzer soll soweit durch Dialog Unterstützt werden, dad 
möglichst keine EDV-Kenntnisse notwendig sind, um Fragestel- 
lungen selbst bearbeiten zu können. 

- Das System muß variabel seln, um eine. große Anpassung an 
das Aufgabenprofil zu erreichen, 


2, Konzeption des Auswertungssystems 
Die Konzeption des Auswertungssystems sieht 3 Teilbereiche 


vor: 

- Datenbereitstellung 

- Transformation von Taten 

„die eigentlichen statistischen Verfahren. 


Zum Bereich der Datenbereitstellung gehört die Möglichkeit,. 
Datenfelder einzugeben (wahlweise Über verschiedene periphe- 
re Geräte), sie zu ändern, Daten einzufügen, Tabellen der 
Daten auszugeben, Datenfelder zu überprüfen (auf bestimmte 
Randbedingungen, um Fehler weitestgehend auszuschalten) und 
zu löschen, 

Der Nutzer kann hier zwischen den einzelnen Verfahren wäh- 
len und kann jederzeit einen gewählten Arbeitsgang abbrechen, 
um mit einem anderen fortzufahren. 

Nachdem die Daten in der gewünschten Form zur Verfügung ste- 
hen, erweisen sich. oftmals Transformationen als zweckmäßig. 


Transformation _von_ Daten_ 
Hier soll dem Nutzer die Möglichkeit gegeben werden, tiber 
die Verknüpfung vorhandener Operatoren (+,-,-.: Fkt) die 
gewünschten Transformationen anzugeben und auf bestimnten 


Datenfeldern anzuwenden. 
29% 


328 


Jetzt. sind die Datenfelder in der Form vorhanden, wie sie- für 
die Anwendung eines statistischen Verfahrens benötigt werden, 
Anschließend wird das entsprechende Verfahren aufgerufen, 

Es ist möglich, von einem Verfshrensbereich zu einem anderen 
zu springen, je nach Bedarf ist so eine relativ optimale Be- 
arbeitung einzelner Fragestellungen möglich. 


3. Konzeption. der Dialoggestaltung 


Um eine konkrete Aufgabe zu lösen, sind jeweils nur bestimmte 
Berechnungen und: Verfahren notwendig. So ist es erforderlich, 
den Rechenprozeß entsprechend steuern zu können, Weiterhin ist 
es wichtig, dem Anwender einfach und übersichtlich die Auswahl 
von Verfahren bereitzustellen und ihm durch einfache, möglichst 
an keine bestimmte Formen gebundene, Eingabemöglichkeiten die 
Arbeit zu erleichtern. 
Somit ergeben sich für die Dialoggestaltung: zwei wichtige Auf- 
‘gaben: 
- die Steuerung des’ Rechenprozesses selbst (Ablaufsteuerung) 
- Unterstützung bei der eigentlichen Lösung, wobei hier folgende 
fälle zu unterscheiden sind: 
Formulierung der gewünschten Eingabeparameter mit ent- 
sprechender Fehlerkontrolle und, falls notwendig, wie- 
derholtem Aufruf zu Eingabe 
. Meldung von Fehlern und Hinweise zu ihrer Beseitigung 
. Angebot von Verfahrenslisten 
Hinweise auf Voraussetzungen, die bestimmte Verfahren 
verlangen,und Angebot entsprechender Prüfverfahren 
(so daß grobe Anwendungsfehler vermieden werden können) 
Soweit möglich Angebot der Ergebnisse in verbaler For- 
mulierung. 


Diese Hilfen werden bereitgestellt, um den Rechenprozeß für einen 
Laier handhabbar zu gestalten und ihn damit die selbständige 
Lösung zu ermöglichen. Der Dialog kann und soll aber nicht 
Kenntnisse der medizinischen Statistik ersetzen, er kann aber 

bei vorhandenen Kenntnissen oder entsprechender vorheriger 
Information Hilfestel:iung in Umgang mit den Verfahren bieten, 


= 
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Die genannten Anforderungen sind mit Hilfe der SKR-Rechner 
Si4-10, SM4-20 gut realisierbar. Durch Benutzung von Over- 
lay-Strukturen und die Steuerung über Indirekt-File-Komman- 
dos ist der zur Verfügung stehende HS„Platz optimal aus- 
nutzbar. Ebenso wird von Datenmengen ausgegangen, die auch 
von Äleinrechentechnik sinnvoll bewältigt werden können; 
für extreme Anwendunssfälle ist das Auswertungssystem nicht 
ausgelegt. 
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Erfahrungen bei der Gestaltung und mehrfachen Nutzung vorgefer- 
tigter Grundsoftware in der technischen Vorbereitung 


1. Binführung 


Die technische Vorbereitung der Produktion beinhaltet das Vor- 
ausdenken von Erzeugnissen und ihrer Herstellung. Die Rationali- 
sierung diesas informationsverarbeitenden Prozesses erfordert den 
kinsatz der Rechentechnik. Unter der rechnergestützten technischen 
Vorbereitung (CAE) verstehen wir das Erarbeiten, Speichern und 
Ausgeben der technischen Dokumentation durch die EDVA auf der 
Grundlage der Kommunikation zwischen Ingenieur und Rechner. 
Schwerpunkte der Nutzung der Leistungsfähigkeit der EDVA zur Un- 
terstützung der Konstrukteure und Technologen sinds 


- die Speicherung der Daten und Programme, 

- die Zugriffe auf die Daten, 

- die Durchführung von Berechnungen und Entscheidungen, 
- die Ausgabe der technischen Dokumentation. 


Mit den EDVA des ESER ist eine einheitliche, leistungsfähige Re- 
chentechnik eingesetzt, die über einfache und programmierbare 
Abonnentenpunkte von Arbeitsplatz der Ingenieure aus genutzt wer- 
den kann. Dabei steht die Entwicklung von Rationalisierungslösun- 
gen für die technische Vorbereitung als Herausforderung ‘an die 
schöpferische Tätigkeit der Ingenieure und Wissenschaftler. Sie 
erfordert die. Systematisierung und Abstraktion der wissenschaft- 
lich-technischen Erkenntnisse und Erfahrungen von Konstrukteuren 
und Technologen. 


Das Ziel ist dann die Umsetzung der abstrahierten Ergebnisse als 
Modelle in der Form von Daten und Programmen. Dadurch wird es 
möglich, diesen durch hohe Kompliziertheit und Komplexität ge- 
kennzeichneten informationsverarbeitenden Prozeß teilweise oder 
ganz dem Rechner zu.-übertragen. 
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2. Strategie und sntwicklung vorgefertigter Grundsoftware für 


die rechnergestützte technische Vorbereitung 


Die für ESER bereitgestellten -Betriebssysteme sind durch hohe 
Leistungsfähigkeit. gekennzeichnet. Sie erfordern für ihre Nutzung 
die Spezialkenntnis der Rechentechnik. 

Rechnergestützte Lösungen zur technischen Vorbereitung müssen je- 
doch bevorzugt von Konstrukteuren und Teohnologen mit hoher Fach- 
kenntnis erarbeitet werden. Die Komplexität und Kompliziertheit 
der zu erarbeitenden ilodelle erfordert die volle Ausschöpfung der 
Leistungsfähigkeit moderner EDVA. Deshalb ist es notwendig, daß 
durch Spezialisten der Softwareentwicklung verallgemeinerte 
rechnerorientierte Komponenten als Grundsoftware bereitgestellt 
werden, die die Konstrukteure und Technologen in dle Lage verset- 
zen, ohne Spezialkenntnisse der Rechentechnik ihre Lösungen pro- 
blemorientiert zu erarbeiten und anzuwenden. Die Umsetzung dieser 
Strategie führt zur Entwicklung von 2-Komponenten-CAD-software, 
wie sie von Krause /1/ beschrieben wurde. 

Diese verallgemeinerten, rechnerorientierten Komponenten tragen 
den Charakter eines technischen Datenbankbetriebssystems (DBBS), 
das von kommerziellen DBBS signifikant verschieden ist. Mit Hilfe 
dieses DBBS können die Konstrukteure und Teohnologen den Rechner 
unmittelbar zur Realisierung: ihrer betriebsspezifischen Modelle 
nutzen. 

Die vom Datenverarbeitungszentrum Magdeburg im Auftrag des VEB 
Werkzeugmaschinenkombinat "7. Oktober" Berlin entwickelte Ratio- 
nalisierungslösung RTV /2/ genügt den definierten Anforderungen 
von 2-Komponenten-CAD-software. RTV besteht aus der rechentech- 
nischen Grundsatalösung, mit deren Hilfe eine Reihe von Anwender- 
lösungen gestaltet wurden und noch gestaltet werden. (Bild 1). 
Aus den Erfahrungen und Ergebnissen dieser nach einheitlichen 
Methoden entwickelten Anwenderlösungen resultiert die technolo- 
gische Grundsatzlösung, die verallgeneinerte Modelle der Anwender- 
lösungen beinhaltet. 


332 


allgemeines Sprachkonzept 


PL/1- 
Compiler 


. Programn- und 
Datenbasis der 
technologischen 

: Grundsatzlösung 


Betriebssystem O0S/ES 


Datenbankbetriebssystem RTV 
(rechentechnische Grundsatzlösung) 


1. 2° .oi. Ds 1.12. oe... De 
"Ibetriebliche Anwenderlösung 


Datenbasen der 
technischen 
Dokumentation 


Bild 1: Ubersioht zur Rationalisierungslösung RTV 
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3. Die rechentechnische Grundsatzläsung RTV — ein technisch 
‚arlentiertes Datenbankbetriebssystem 


3.1. Sprachkonzept: 


In internationalen Veröffentlichungen wird als Programmiarsprache 
für die rechnergestützte technische Vorbereitung in starken. Ma- 
Be auf FORTRAN orientiert. Das hat seine Begründung unter ande- 
rem in der historischen Entwicklung und in der Forderung nach 
Poptabilität der Software. Es gibt jedoch bereits nauere Systen- 
entsicklungen, die als entscheidenden Vorteil gegenüber ent- 
sprechenden FORTRAN-Implementierungen moderne Programmierspra- 
chen nutzen und die dadurch nach eigener Aussage einen quali- 
tätssprung erreichen konnten /3/. Die erhöhta Leistungsfähigkeit 
der modernen Programmiersprachen drückt "sich u. a. aus in: 


- flexibale Verwendung von Zeichen- und Bitketten, Strukturen 
und Listen, 

- interaktive Anwendung, 

- Einbindung von Progreannen, die in anderen Sprachen programmiert 
sind (FORTRAN, ASSEMBLER), 

- klare Strukturierung. 


Da im RGW mit dem BSER einheitliche Rechentechnik genutzt wird, 
ist hier die Portabilität hinsichtlich der eingesetzten Groß- 
rechner gelöst. 

Ausgehend von diesen Gesichtspunkten wurde PL/1 als Datennani- 
pulationssprache für RTV genutzt. Die Anwendung der Progranmier- 
sprache PL/1 und der in sie eingebetteten Zugriffstechniken dea 
DBBS ist in der methodischen Richtlinie zur Programmierung von An- 
wendersprachen beschrieben. In Anlehnung an moderne Programmier- 
sprachen wurde ein allgemeines Sprachkonzept (Bild 2) entwiokelt, 
das auf die Aufgabenklasse der deskriptiven Spraohen für die 
technisohe Vorbereitung ausgedehnt ist. 

Die Schlüsselworte (Wortsymbole) der deskriptiven Sprachen und 
der Aufbau der Progrannsätze ünd Programme sind durch den Anwen- 
der entsprechend der ausgewählten Aufgabenklasse frei wählbar. 
Sie werden auf der Grundlage des allgemeinen Spracohkonzeptegs ver- 
einbart. 


allgemeines Sprachkonzept 


Kommandosprache für den Dialogs (TS0/DSL/JDS) 


Datenmanipulationssprache 


-Datendefinitionssprache SYX 


Proceduren 
Tabellen 
Werkstückbeschreibung 


Technologiebeschreibung 


Bild 2: Sprachkonzept für die rechnergestützte technische 
Vorbereitung 


Datenverwaltungssystem 


Eingabesystem 


Verarbeitungssysten - 


 Ausgabesystem | Generatoren 


Bild "3: Datenbankbetriebssystem für die rechnergestützte 
technische Vorbereitung 


335 


Eine methodische Richtlinie zur Vereinbarung und Verwaltung von 
Bingabesprachen einschließlich der Datendefinitionssprache SYX 
unterstützen den Anwender bei der Entwicklung seiner Sprachen. 


‚Für folgende Aufgaben wurden bisher Sprachen vereinbart; 


- YVWerkstückbeschreibung, 

- Technologiebeschreibung, 

- Arbeitsgangausarbeitung, 

- maschinelle NC-Progrannierung, 

- Tabellen zur Speicherung von Normativen, Natrizen und Katalogen, 
- Proceduren zur Speicherung beliebig strukturierter Daten, 

- festformatige Sprachen zur Belegerfassung, 

- Recherche in den Daten der technischen Dokumentation, 

- Moduldefinition, 

- Datendefinition. 


Mit Hilfe der methodischen Richtlinie und der Sprache SZX sind die 
Anwender in der Lage, selbständig Sprachen zu vereinbaren und an 
die notwendigen Veränderungen anzupassen. 


3.2. Datenverwaltung 


Alle Eingabedaten liegen unabhängig von der Sprache in der Form 
von Quellprogramnen vor und werden mit den Komponenten des Be- 
triebssystems verwaltet. Vorteilhaft wirkt sich hierbei eine lei- 
stungsfähige EDIT-Funktion eines angeschlossenen Dialogsystems 
eus. Die realisierte Möglichkeit des dynamischen Aufrufes von Pro- 
blemprogrammen der Anwender erschließt besonders günstige Mög- 
lichkeiten. Die Problemprogramme können dadurch unabhängig vonein- 
ander geändert, Übersetzt und gespeichert werden. Somit ist ein 
einfacher Änderungsdienst und eine unproblematische Mehrfachnut-- 
zung möglich. 

Aufbauend auf diesen Erfahrungen wurde ein-Modularkonzept entwik- 
kelt und der Systementwicklung von RTV zugrunde gelegt /4/. 

Alle Moduln und Daten werden über ihren Namen aufgerufen. Die Ver- 
bindungen zwischen den iloduln werden nur zum Zeitpunkt des Aufru- 
fes geknüpft. 

Der Zugriff von den Problenprogramnen auf die Daten der Anwender 
wird durch einfache und erweiterte Zugriffstechniken unterstützt. 
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Diese Zugriffstechniken werden über den dynamischen Unterpro- 
grammaufruf aktiviert. Somit kann über das DBBS (Bild 3) auf Ta- 
bellen, Proceduren, Werkstückbeschreibung, Technologiebeschrei- 
bung und die Daten der erstellten technischen Dokumentation zuge- 
griffen werden. Bein Zugriff auf Tabellen können gleichzeitig 
mehrstufige Entscheidungskriterien zur Auswahl der Daten wirksam 
werden. 

Die von Anwender eingespeicherten Tabellen und Proceduren werden 
durch das DbBS in eine speicher- und abarbeitungsgerechte Form 
transforniert. 

Besondere Aufinerksaakeit wurde der Speicherung Und der Auswer- 
tung der Werkstückbeschreibung gewidmet. Sie wird in eine interne 
Normalforn transforniert, die die Struktur und die Daten der 
Werkstückbeschreibung beinhaltet. 

Die einfachen Zugriffstechniken gestatten zum Beispiel: 


- die Bereitstellung eines beliebigen Haßes am Werkstück, 

- die Festlegung einer Zusatzangabe zu diesem Maß, 

- die Anfrage, ob ein Werkstück ein bestimmtes Formelement be- 
sitzt nit gegebenenfalls ‘gleichzeitiger Bereitstellung der Pa- 
raneter des Formelementes, 


Die erweiterten Zugriffstechniken beinhalten unterjanderem den 
Komplexzugriff auf alle Daten der Werkstückbeschreibung einer de- 
finierten Werkstückklasse oder einer Struktur innerhalb einer 
Werkstückbeschreibung. Dadurch wird besonders die Zntwicklung von 
Anwenderlösungen unterstützt, die das Variantenprinzip nutzen.” 
Analog werden die Zugriffe auf die einfachen Datenstrukturen der 
Technologiebeschreibung und der übrigen Fingabedaten gelöst. 
Spezielle Komponenten des DBBS sichern die Verwaltung und den 
Anderunssdiienst der technischen Dokumentation, speziell der Ar- 
beitspläne und der Strukturlisten. 

wirl von Anwender ein eigenes kommerzielles Datenverwaltungs- 
system für diese Probleme eingesetzt, so werden die Anschlußbe- 
dingungen’ gesichert. 
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3.3. Generatoren zur Anpassung der Grundsatzlösung 


zu 


Für definierte Teile der Anwenderlösung wurden spezielle Genera- 
toren erarbeitet, die aus den mit Hilfe der Datendefinitions- 
sprache SYX durch den Anwender erstellten Beschreibungen spezifi- 
sche Moduln erzeugen. 


Das sind besonders: 


- anwenderabhängige Teile des Sprachübersetzers für deskriptive 
Sprachen, ? 
- Hoduln zur Anpassung der Datelverwaltung und der Zugriffstech- 
niken, 

- anwenderspezifische Moduln zum Belegdruck, zur Ausgabe der 
Steuerinformation für NC-Maschinen und für Zeichentische so- 
wie zur Speicherung der technischen Dokumentation: 


Die Anleitung zur Generierung wird in. der methodischen Richtli- 
nie zur. organisatorischen Anpassung der Anwenderlösungen gegeben. 


4. Erfahrungen bei der mehrfachen Anwendung 


Seit 1917 wird die Rationallsierungslösung RTV im Routinebatrieb 
auf ESER-Anlagen genutzt /5/. Mit der Realisierung weiterer An- 
wenderlösungen wurde die Leistungsfähigkeit, Allgemeingültigkeit 
und Anwenderfreundlichkeit der Lösungen schrittweise erhöht. 
Anhand einer methodischen Riohtlinie zur betrieblichen Anpassung 
und Entwicklung sind die Konstrukteure und Technologen der Anwen- 
derbetriebe in der Lage, selbständig ihre Anwenderlösungen zu ge- 
stalten und weiterzuentwickeln. Durch zentral organisierte und 
durch betriebsbezogene Schulungen wurden ausgewählte Kader (Sys- 
teminzenieure) speziell für diese Aufgaben qualifiziert. 

In jedem Anwonderbetrieb wurde eine Arbeits- und Forschungsgenieln- 
schaft gebildet, in der die späteren Nutzer der Rationalisierungs- 
lösung, die Systemingenieure, betriebliche Organisatoren und die 
Entwickler der rechentechnischen Grundsatzlösung geneinsan an der 
Realisierung dieser Aufgaben arbeiten. Diese Zusammenarbeit ist 
gekennzeichnet durch Praxisnähe, eine straffe, vertraglich ver- 
ankerte Organisation und detdmierter Arbeitsteilung. 
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Progranm- und Datenbasis der technologischen Grundsatzlösung 


(allgemeingültige Anwendermnoduln) 


‚» Problemprogramme (Berechnungen, Entscheidungen) 
. Tabellen )Normative, Kataloge, Standards, ...) 

« Proceduren (Datenstrukturen, Texte,...».) 

. SYX-Standardsprachvereinbarungen 


Programm- und Datenbasis der Anwenderlösung 


Problemprogramne 

Tabellen 

Proceduren 
SYX-Sprachvereinbarungen 
Werkstückbeschreibungen 
Teohnologiebeschreibungen 


Datenbasis der technischen Dokumentation 


« Stücklisten 


. Arbeitsplanstamnkarten 


Bild 4: Programm- und Datenbasen 
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Sie hat eine entsoheldende Rückkopplung auf die Weiterentwiok- 
lung der reohentechnischen Grundsatzlösung. 


Die einheitliche Organisation der Erarbeitung von Anwenderlösun- 
gen, die einheitlichen methodischen Richtlinien und die einhelt- 
liche rechentechnisohe Grundsatzlösung bewirken, daß die erarbei- 
teten anwenderspezifischen Moduln zwischen den Anwendern ausge- 
tauscht werden können. Im Rahmen einer Üüberbetrieblichen Nutzer- 
gemeinschaft wird zielgerichtet daran gearbeitet, allgemeinglil- 
tige, nacohnutzungsfüähige Moduln zu entwickeln oder als Vertrags- 
forschung entwickeln zu lassen. Diese Moduln stehen in der zentra- 
len Programm- und Datenbasis (Bild 4), der technologischen Grund- 
satzlösung, allen Nutzern zur Verfügung. 


Die technologische Grundsatzlösung beinhaltet: 


- Problemprogramne, 
- Tabellen und Prooeduren, 
- SYX-Standardsprachvereinbarungen. 


Bei der Verwaltung der technologischen Grundsatzlösung gelten fol- 
gende Grundsätze: 


Der Erarbeiter eines Moduls übernimmt dessen langfristige Pflege 
und Wartung. Bei inhaltlicher Erweiterung des Moduls muß dieser 
unter einem. neuen Namen eingespeichert werden. Zur Beschreibung 
und Verwaltung der Moduln wird eine Moduldokumentationssprache be- 
reitgestellt. 


5. Schlußbemarkungen 


Die Entwicklung der Rationalisierungslösung RTV als allgemeine 
verfügbare Grundsoftware mit daraus abgeleiteten betrieblich ge- 
nutzten Anwenderlösungen hat sich bewährt /b/, /7/. Besonders 
vorteilhaft ist dabei die unabhängige Entwioklung, Bereitstellung 
und Wartung der rechentechniscohen Grundsatzlösung für eine Viel- 
zahl von Anwendungsfällen in Einheit mit der selbständigen Gestel- 
tung und scohritthaltenden Adaption von Anwenderlösungen durch be- 
triebliche Entwicklerkollektive. Ein wichtiges Merkmal ist die 
Herausarbeitung verallgemeinerter Woduln der Anwenderlösungen und 
ihre Einbindung in eine technologische Grundsatzlösung für alle 
Nutzer. 
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Daduroh wird der Entwicklungsaufwand für neue Anwendungsfälle wei- 
ter reduziert bei gleiohzeitiger Erhöhung ihres Niveaus und ihrer 
volkswirtschaftlichen Wirksankeit. 
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Aden, Horst 


Listgenerator LSDAT 


Der Listgenerator LSDAT dient der Auswertung sequentieller 
Datenbestände und liefert in einem Arbeitsgang Zusammenstel- 
lungen von verschiedenartigen Listen zu geschlossenen Doku- 
menten (Listkomplexen, siehe Abb. 1). 

Zur Kodierung von. LSDAT-Anweisungen sind keine Programmier- 
kenntnisse erforderlich, Vorausgesetzt wird nur, daß der An- 
wender mit dem Aufbau von Datensätzen mit Ordnungsbegriffen, 
den Prinzipien ihrer Sortierung und der Gruppenbildung ver- 
traut ist. 

LSDAT ist eine Komponente des Datenverarbeitungssystemse 
vıv2/Bom. %) 
Verwaltung der Datenbestände technologisch unterstützt. Die 
Generierungstechnologie des VIV2/BOM gestattet dem Anwender, 
mit formalen Speichernanmen zu arbeiten, ohne sich um die kon- 
krete Lokalisierung der aktuellen Speicher kümmern zu müssen. 
Alle Anweisungen sind in der vom Assembler und den ES/O0S- 
Dienstprogrammen her: bekannten Form zu kodieren, wobei die 
Syntax der Schlüsselwortoperanden problembedingt erweitert 
worden ist.. Schlüsselwörter können soweit verkürzt werden, 
wie ihre Eindeutigkeit zuläßt. Damit wird ein Minimum an Ko- 
dieraufwand bei hoher Flexibilität und Erweiterungsfähigkeit 
der Sprache erreicht. 


und somit von der Pflege der Anweisungen bis zur 


Die Anwendung von LSDAT setzt einen vom Anwender seinen Be- 
dürfnissen entsprechend einzurichtenden DASS-Referenzspeicher 
voraus. Dieser Speicher bedarf keiner Reorganisation und kann 
wahlweise mit Sicherung der Umsätze zur automatischen Rekon- 
struktion betrieben werden. Die Pflege der gespeicherten Daten 
ist an das Programmsystem PORG 2) 
einfach. 


angelehnt und damit sehr 


1) Eine Sondernummer der Zeitschrift "Rechentechnik - Datenver- 
arbeitung” zu VIV2/BOM wird vorbereitet. 


2) Das Pfogrammverwaltungssystem PORG wird vom Kombinat Robotron 
vertrieben. 
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Abb; '1- "Schematische Darstellung eines Listkomplexes mit 
Inhaltsverzeichnis 


7) 


= = Listenüberschnft I 2] 


Ausgabe im N IDONSVELZEINIS 
Listmuster zu IR N - 


kodieren ter 
Komplex - 
w überschrft 1 — 


Überschrift 2... —:-- 
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Alle Datenstrukturen werden mit Datenbeschreibungstafeln 
festgelegt. Jedes Datenelement dieser Strukturen wird mit 
einem Namen versehen. und durch eine Relativadresse, seine 
Länge und einen Datentyp charakterisiert. Der Datentyp hat 
eine funktionelle Komponente, die angibt, ob das Datenelement 
eine Ordnungsfunktion (Identifikator) hat und eine Komponente, 
die die Darstellungsform beschreibt. 
Darstellungsformen sind: Zeichenketten, Bittketten, Zahlen. 
Datenbeschreibungstafeln sind als Objekte des Referenzspei- 
chers zu speichern. 
Jedem im Datensatz angegebenen Ordnungsbegriff muß im Refe- 
renzspeicher eine Nomenklatur zugeordnet werden. Die Nomen- 
klatursätze enthalten den Schlüssel und weitere Informationen 
wie Texte, Sortiernummern, Angaben zur Maßeinheitenbehandlung 
und anderes nach Belieben des Anwenders. Die Struktur der 
Nomenklatursätze wird mit Datenbeschreibungstafeln festgelegt. 
Die Nomenklaturen werden den Ordnungsbegriffen mittels Be- 
griffstabellen zugeordnet. Auf dieser Basis können Listmuster 
entworfen, kodiert und in den Referenzspeicher eingegeben wer- 
den. Nach jeder Eingabe oder Pflege eines Listmusters tritt 
der Listmusterkonpiler in Aktion und erzeugt ausführbare Pro- 
grammkode und Datenbereiche, die im Referenzspeicher als wei- 
tere Segmente zum Listmusterquelltext gespeichert werden. 
Ein Listmuster wird mit’ einer Identifikationsanweisung (LMID) 
eingeleitet, in der die Datenbeschreibungstafel zu den Daten- 
sätzen genannt wird. Über die Ordnungsbegriffe der Datensätze 
wird damit auch der Zugang zu den Nomenklatursätzen des Refe- 
renzspeichers gewährleistet. Mit Anweisungen zur Vereinbarung 
von Variablen (LMVP) werden Arbeits- und Parameterfelder fest- 
gelegt und wahlweise initialisiert und bei Bedarf ihr zulässi- 
ger Wliertevorrat festgelegt. 
Durch die Vereinbarung synthetischer Ordnungsbegriffe (LMVS) 
und ihre Versorgung mit Werten mittels Bedingungen an den 
Datensatz insbesondere an die Ordnungsbegriffe, gelingt os, 
Datensätze zusammenzuführen, die sonst mit keinerlei Sortie- 
rung nach den Ordnungsbegriffen zusammengeführt werden können. 
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In einer Anweisung zur Ordnung der Daten (LMOG) werden die 
Ordnungebegriffe in der Reihenfolge ihres Ranges aufgeführt 

und mit dem Hinweis: Sortierung nach den Schlüsseln oder den 
Ordnungenummern aus der zugehörigen Nomenklatur vorsehen. 

Durch Einfügen von Schaltervariablen besteht die Möglichkeit, 
die Gestaltung der Listen zu bereichern. 

Letzten Endes werden die Daten mittels seiner Reihe von List- 
mustersatzanweisungen (LMSA), die über ihren Ordnungsbegriffs- 
oder Schalternamen den Stufen der Listmusterordnungsanweisung 
zugeordnet sind, ausgegeben. Die Listmustersatzanweisungen sind 
entweder vom Typ Kopf und werden zum Beginn der Gruppe ent- 
sprechend dem Gruppenwechsel oder einer Schalterstellung nach 
fallender Hierarchie ausgeführt oder sie sind vom Typ Fuß und 
werden am Ende der Gruppe vom niedrigsten Niveau beginnend bis 
zur höchsten Gruppenwechselstufe oder dem höchsten Schalter in, 
der Stellung "ein" ausgeführt. Vor jeder Ausgabe wird, falls 
vorhanden, eine zugehörige Aktion ausgeführt, Die Aktionen be- 
stehen aus Folgen von Ergibtanweisungen bzw. bedingten Anwei- 
sungen. In den Aktionen können Rechnungen ausgeführt werden. 

Die logischen Ausdrücke für die Bedingungen und die arithne- 
tischen Ausdrücke für die Rechnungen werden in der aus der 
Elementarmathematik bekannten Form kodiert. Mittels sogenannter 
Listfunktionen ist es möglich, insbesondere kompliziertere 1lo- 
gieche Bedingungen leicht zu formulieren. 

In einem Arbeitsgang können Daten in mehreren Listen mit unter- 
schiedlicher Sortierung entsprechend den vorbereiteten List- 
mustern ausgegeben werden. Zu diesem Zwecke ist ein Abruf zu 
kodieren. Der Abruf steuert die Ausgabe eines oder mehrerer 
Listkomplexe. Jede Ausgabe von Listkomplexen wird durch eine LK- 
Anweisung eingeleitet, die im wesentlichen die Listkomplexüber- 
schrift und Angaben zur Geheimhaltung enthält. Danach folgen LM- 
Anweisungen, die das jeweilige zu benutzende Listmuster und die 
Listenüberschriften festlegen. Auf jede LM-Anweisung folgen An- 
weisungen, die der Versorgung des Listmusters mit Parametern 

und Daten dienen. In einer Gruppe von Ordnungsbegriffen. können 
mehrere verschiedene Listen ausgegeben werden, indem in der Folge 
der LM-Anweisungen zu den unterzuordnenden Listen ein entsprechen- 
der Parameter kodiert wird. 
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Die Listung wird mittels einer Steueranweisung gestartet, 

in der die Eingabespeicher, die Datenstruktur, der Abruf, 

die Ausgabespeicher und technologischen Parameter zu den 
Arbeitsspeichern angegeben werden. Die auf magnetische Daten- 
träger ausgegeben Listkomplexe können mittels DIAL am Bild- 
schirm betrachtet und mittels MBD in beliebiger Anzahl und 
auch auszugsweise gedruckt werden. 

Mit dem folgenden Beispiel wird die Kodierung einer Datenbe- 
schreibungstafel, eines Listmusters, eines Abrufs und einer 
technologischen Anweisung angedeutet. 
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Beispielliste 


DOKUMENT NR. D GEH 3782/5 
SEITE; 1 
DATUM: 10.05.1982 
KAPITEL NR, K 


obi-text 
 gb2-text_ _ 


SPALTEN- SPALTEN- SPALTEN- 
VEB 1 


m (m (m (mE (mm Gb GE Gum Gmb ED 


ob3-text 
ob4-text dfi-df2 
ob4-text df1-df2 


ob3-text 
ob4-text dfi1-df2 
ob4-text df1-df2 


Darin bedeuten: 

081,0B2,0B3,08B4 - willkürliche Namen für Ordnungsbegriffe mit den 
Schlüsseln ob1,0b2,0b3 und ob4 

obi-text, usw. - Texte zur Erläuterung der Bedeutung der Schlüssel 
ob1 usw.,. die in den Feldern TEXT der Nomenklatursätze zu OB1 
usw. enthalten sind. Adressierung OB1.TEXT usw, 

dfi,df2 - Werte aus den Feldern DF(1) und DF(2) der Datensätze 

s1,s2 - Summen der Werte dfi1,df2 innerhalb der Gruppen zu OB3 
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Die Datenbeschreibungstafel DSDBT für die Datensätze lautet: 


De 


BSR 69 Datensatzlänge 

STR 0B1,0,N,2,1 Ordnungsbegriffe (OÖ) 

STR 082,0,N,2,3 numerisch linksbündig 

STR 083,0,N,4,5 gepackt (N) in 2 bzw. 4 Bytes, 

STR 084,0,N,2,9 d.h. vier- oder achtstellig 
... an den Adressen 1,3,5 bzw. 9 


STR DF,D,E,4,13,12 Datenfeldvektor (D) mit zwölf Feldern vom 
Gleitkommatyp (E) der Länge vier ab Adresse 
13 im Datensatz 

Der Einfachheithalber wird für alle Nomenklaturen die folgende 

gleiche DBT zugrunde gelegt: 


BSR 41 Nomenklatursatzlänge 

SOR 083 Sortierung im Referenzspeicher nach den 
Schlüsseln 

STR 081,0,N,2,1 

STR 082,0,N,2,1 Schlüsselvereinbarungen, 

STR 08B3,0,N,4,1 alle Schlüssel ab Adresse 1 


STR 084,0,N,1,1 

STR LFDN,D,H,2,5 laufende Nummer für Sortierung in den 
Listen 

STR TEXT,D,T,21,7 Text zum Schlüssel 

STR AUN,D,B,15,28 Bitvektor zur Bildung, von Teilnomenklaturen 
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Kodieruno des Listmusters für die Beispielliste 


Name des Listmusters 
LMID NAME=LMBSP ‚DBT=DSDBT 
Sortierung und Satzfolge festlegen: 


LMOG (NAME=OB1,ONR= WDS), SORT NACH SCHLUESSEL 
(NAME=0B2,AWS=(1020,7049,3001,4081)), AUSWAHL UND 
SORTIERSCHLUESSEL 
(NAME=0B3 ,ONR=LFDN), SORT NACH LFDN DER NOMENKL 


(NAME=0B4 ‚ONR=SORTVAR) SORT IM ABRUF FESTLEGEN 
Variable festlegen: ö 
LMVP (NAME=SORTVAR,TYP=DC ,LNG=8,INIT="LFDN', 

WVRT=( 'LFDN',' WDS')), 

(NAME=S , TYP=DD ,ANZ=2 SUMMENREGISTER 
Anweisungen zur Berechnung und Ausgabe der Daten: 
Die Anweisung mit NAME= SWB wird bei jedem Blattwechsel durch 
Wechsel der Schlüssel OB1 oder OB2 und bei jedem Blattüberlauf 
ausgeführt. WZ (Zeilenwechsel), RS (Lücke), A und F sind Format 
elemente. 


LMSA NAME=0B1,TYP=KO ,FORMAT=( ‚WB) BLATTWECHSEL 
LMSA NAME=0B2,TYP=KO,FORMAT=( ‚WB) BLATTWECHSEL 
LMSA NAME=#SWB ,TYP=KO , FORMAT=(XSWBFMT) SPALTEN 


LMSA NAME=0B3 ,TYP=KO,AKTION=(S(1)=8,5(2)=), 
FORMAT=((083,083.TEXT), (YZ,A,RS(6),A)) 

LMSA NAME=083,TYP=KO, 
AKTION=(S(1)=S(1)+DF(1),S(2)=S(2)+DF(2)). 
FORMAT= ( (084 ,084..TEXT ,DF(1) ,DF(2),DF(2)-OF(1)), 

(WZ,RS(4) ,A,RS(2),A,RS(1),(3)F(9,2))) 
LMSA NAME=083 ‚TYP=FU,FORMAT=(( "nun" ‚S(1),5(2).,5(2)-S(1)), 
(WZ,(A(4).,RS(n),(3)F(9,1))) 
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Anweisung zur Ausgabe der Spaltenüberschrift, auf die mit 
/ 
SSWBFMT bezug genommen wird 


SWBFMT FORMAT ‚WB,('0B:',0B1,0B1.TEXT),(A,A,RS(2),A). x 
('0B2:',082,082.TEXT),(RZ(1),A,A,RS(2),A), % 
(n)?-",(RZ(1),A(n)), " 
'083 "{RP(2,1),A). ” 
OB4 ',(RP(3,1),A), D 
* SPALTEN- SPALTEN- SPALTEN- *",(RP(2,n),A), 
VEB1 LEB2 UEB3 ‚s{RP(3,n),A), 
(n)'-".(RZ(1).A) 
Kodierung des Abrufs 
Listkomplex einleiten 
LK FORM=62,EXFL=(5,2) „GGR=GEH,GNR=3762/5, ”“ 
VEB11="DOKUMENT NR. D*' „UEB21=*" * „UEB31=" 2) 
SNR=4 

Listmuster auswählen und mit Uberschrift versehen 

LM NAME=LMBSP ‚BSPR=1,UEB11="KAPITEL NR. K*, '“ 


VEB21=YYY,IVZi1=... 

\Vertzuweisung an Variable im Listmuster 
LV SORTVAR= WDS # 
Datenauswahl für das Listmuster. Es sind.zwei Teilmengen auszu- 
wählen. In der ersten Teilmenge, sollen nur Sätze ausgewählt wer- 
den, in denen OB1 Schlüssel enthält, deren zugeordnete Nomen- 
klatursätze. im Feld AUN-in den Positionen 1,5,7:!oder 20.eine 1, 
enthalten. Der Schlüssel 082 kann beliebige Werte annehmen, wird 
aber durch LMOG auf die dort angegebenen vier Schlüssel be- 
schränkt. Der Schlüssel 083 kann nur ganze Hunderterwerte an- 
nehmen. OB4 darf nur ungleich 0000 sein. .Die zweite Teilmenge 
wird neben den Bedingungen an die Ordnungasbegriffe durch eine Be- 
dingung an die Datenfelder bestimmt. 

.‚— entspricht & 


081.A,N:(1,5,7,70) ,0Ob2:nnnK, r 
CB3: (#2) ,OB4 =0000 
Au OB1.AUN: 6,0B2 nn ,0B3:(0000-5000,9000), —\ ” 
© vB4,LFON:(200-759),.(UF(2)-BEF(1)/DF(1) 100 
LH 
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Die technologische Anweisung lautet: 

./ LSDAT DBT=DSDBT ,ABRÜFSÄBRB ,LISTEN=LST1, 
./ INHALT=SYSA ,ARB=?AUSW, 

./ EINO1=STAMMN 


Aden, H., Berlin 
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Entscheidungstabellenvorübersetzer "WET" 
1. Srundsätze 


Entscheidungstabellen gewinnen .in der Praxis immer größere bedeutung. Sie er- 
möglichen dem Fachpersonal, ihre Probleme in einem schnell erlernbaren, EDV- 
gerechten System zu formlieren. 

Allerdings zeigt es sich, daß der EDV-gerechte Entwurf in Entscheidungstabel- 
len und ihre direkte Umsetzung in eine Progranmiersprache den Anforderungen 

der Praxis nicht gerecht wird. Verlangt wurden, neben der einfachen und gemisch- 
ten Notation, weitgehende Prüfungen und Optimierungen. Im Gegensatz dazu stand 
die Forderung nach Geschwindigkeit an zweiter Stelle. Wir haben uns deshalb ert- 
schlossen, alle verfügbaren Tests zum Ermitteln von widersprüchlichen und redun- 
danten Regeln aufzunehmen. Die Listung aller Entscheidungstabellen während der 
Umformung und Optimierung und die Aufnahme einer Laufzeitunterstützung zur Er- 
mittlung von Bedingungskonstellationen, die nicht in der ursprünglich entworfe- 
nen Tabelle enthalten sind. Für.die Implementation wurde der kMarkierungsalso- 
rithmis verwendet. Gegenüber dem Verzweigungsalgorithmus ist er zwar leichter 

zu implementieren, dafür ist er aber langsamer. Dieser Nachteil wird aber durch 
die umfangreichen Tests ausgeglichen. 


2. Der Entscheidungstabellenvorübersetzer "WET" 


WET ist ein Entscheidungstabellenvorübersetzer für die Programmiersprache .PL/1 
unter der Steuerung des 0S/ES (MVT/MFT). z 


2.1. ET-Aufbau 


| Bedingungs- | | 


| 
teil | | 
Ks j Regelteil | 
else (Bedingungs- und 
| Aktions- \ - Aktionsanzeiger) 
teil f 
| 


Folgende iiotationen sind dabei möglich: 


2.1.1. Begrenzte ET 


Bedingungszeile: Ir A=B Neuen YN 
Aktionszeile: A=E*C Ve ss -X 
oder: PERFOR# AA BD 6 GE RERIEFERERE XXX 


Semikolon. Reicht der Platz im Aktionsteil nicht zus, so kann die PERFOR- 
weisung benutzt werden. 
Trifft für eine Regel die angegebene Bedingung zu, so ist ein "Y" anzuseter. 
Trifft sie richt zu, ist ‘ein "u 
E u, ist ein "N ; ar e 
zu notieren. Ist die Aussage der Bedingung chne 
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Bedeutung, so daß ein '"-" (DON T CARE) zu schreiben. Für auszuführende Ak- 
tionen wird in der Regel ein "X" geschrieben. Für nicht auszuführende Aktio- 
nen ein "-". Sollen zur Laufzeit Aktionen ausgeführt werden, für die keine 
Bedingungsanzeiger in der ET enthalten sind, so sind diese Aktionsanzeiger 
als letzte Spalte in der ET ohne Bedingungsanzeiger zu notieren. Dies stellt 
die ELSE-Regel dar. 


2.1.2. Erweiterte ET 


Bedingungszeile: IFA =E B B 
nktionszeile: A= RC Ö 
oder: PERFORH AM AB 


Die erweiterte Notation ermöglicht es, in einer Zeile mehrere Bedingungen bzw. 
Aktionen unterzubringen. Dies fördert die Übersichtlichkeit und Lesbarkeit der 
Tabellen. Treffen Beäingungen oder Aktionen für eine bestimmte ijiegel nicht zu, 
so sind an dieser Stelle Leerzeichen zu schreiben. 


2.1.3. Gemischte Tabelle 


Es ist möglich, die beiden zuerst genannten Formen in beliebiger Abfolge der 
Zeilen gemeinsam zu notieren. 


2.2; Leistungsparameter 


Zur Beschreibung jeder ET werden folgende Parameter verlangt: 


NAME 
SIZE 


Name der ET (genau 5 Zeichen) 
(Bedingungsanzahl, Aktionsanzahl, Regelanzahl) 
Es gelten folgende Begrenzungen: 
Bedingungsanzahl + Aktionsanzahl = 100 
Regelanzahl = 100 
TEXTSIZE = (Breite des Bedingungs-, Aktionsteils, Regelbreite) 
Es gelten folgende Begrenzungen: 


Breite des Bedingungs-, Aktionsteils = 72 
Standard, wenn ausgelassen = 48 
Regelbreite = 70 
Standard, wenn ausgelassen = 1 
BITSIZE = Maximum über die Anzahl aller Bedingungen bzw. Aktionen der im Pro- 
an renden Entscheidungstabellen. 


Dieser Wert wird zur Generierung des PL/1-Textes benötigt. 
lie Begrenzungen ‘im SIZE-Parameter sind Konstanten und lassen sich abhänriz vor 
vorhandenen Hauptspeicherplatz beliebig vergrößern. 


2.3. Wahlfreie Parameter 


SORT = (LIES I COLUENS I ROWS5) 


Der Parameter ermöglicht eine Sortierung nach Zeilen (ohne jede Einschränkung 
möglich), oder nach Spalten oder Zeilen und Spalten (dies kann zu Fehlern füh- 
ren, wenn die Regeln nicht den F-Test bestehen). 
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OPTIONS= (Parameterliste) 


Parameter: 
ELSE - 
LIST, - 


TESTLIST - 


OPEN - 
CLOSE - 


INTERN - 
EXTERN — 
PTEST - 


muß angegeben werden, wenn die ELSE-Regel Anwendung findet. 


im erzeugten PL/1-Text wird die Original ET als Kommentar 
gelistet 


alle Stufen der ET-Umwandlung (von einer, erweiterten oder 
gemischten in eine einfache) und Optimierung werden während 
des Precompilerlaufes aufgelistet 


die ET wird am Regelende verlassen, die Steuerung geht zum 
nächsten Statment nach der ET über 


die ET wird nach Regelende erneut durchläufen, die Tabelle 
muß durch einen Sprung im Aktionsteil verlassen werden 


aus der ET wird eine Statmentfolge generiert 
die ET wird als PL/1-Prozedur generiert 


PTEST wird ausgeführt, fällt er negativ aus, wird das Pro- 
gramm abgebrochen. 


Die Abfolge und Nutzung der Parameter in der Optionsliste ist wahlfrei. 


2.4. _ Zusammenstellung der Tests 
Folgende Tests werden von WET unbedingt durchgeführt: 


2.4.1. Redundanz 


Zwei Regeln-sind identisch. Eine‘ Regel wird gelöscht. 


2.4.2. Widerspruch 


Zwei Regeln mit gleichem Bedingungsteil haben unterschiedliche Aktions- 
teile, der WET-Lauf wird abgebrochen. 


Durch die Option "PTEST" werden folgende Tests durchgeführt: 


2.4.3. PTEST 


Dieser Test nach Pollak garantiert, daß alle Regeln der ET beliebig 
vertauschbar sind. Die erfolgreiche Durchführung des Tests ist Voraus- 
setzung für ein Spalten- oder reihenweises Sortieren der Tabelle und 
für alle folgenden Tests. 

rällt der PTEST negativ aus, wird der WET-Lauf abgebrochen. 


2.4.4. 1. ET-Sesetz nach Greye 


‚Zusammenfassung von zwei Regeln, die sich nur in einem Bedingungs- 
anzeigerpaar (Y,N) unterscheiden. 


2.4.5. 2. ET-Sesetz nach Greve 


Zusammenfassung von zwei Regeln, die sich nur in einem Bedingungs- 
anzeigerpaar (Y,-) oder (il,-) unterscheiden. 
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2.4.6. 3. ET-Gesetz nach Greve 


Unterscheiden sich zwei Regeln in mehreren Beäingungsanzeigerpaaren 
(Y,-) wid/oder (N,-), so werden sämtliche darin enthaltenen Redun- 
danten Regeln gestrichen. 

Die Anzahl der "-" Anzeiger ist für ein Regelpaar auf 7 begrenzt. 


Die Optimierungen 2.4.4. bis 2.4.6. werden jeweils zyklisch wiederholt, bis 
kein entsprechendes Regelpaar mehr auftritt. 


3. Schlußbemerkung 


-Der Übersetzer befindet sich seit einem Jahr in der Praxisanwendung für kleine 
und mittlere Probleme, besonders bewährt hat sich dabei die Umstellung und Op- 
timierung der Tabellen durch den Vorübersetzer in der Entwurfsphase. Es.:konn- 
ten dabei bereits inkorrekte und unvollständige Aussagen entdeckt und korri- 
giert werden. F 
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Böhme, Peter 


Die Anwendung. des Programmpaketes SYSDFV zur Simulation 
spezieller, durch Differentialgleichungen beschriebene 
Systeme 


Vorbemerkungen 
Ziel.des Beitrages ist es, das im ORZ der HLE entwickelte 


Programnpaket SYSDFV zu charakterisieren. Diskutiert wird 
vor allem die Programmstruktur und es werden die Konzepte 
dargelegt, nach denen die Dialogfähigkeit von SYSDFV herge- 
stellt und die Einbindung 'externer' Programmbausteine in- 
SYEDFV realisiert werden soll. Eine ausführliche Darlegung 
des Konzepts von SYSDFV (einschließlich Darstellung der 
Numerik und Angabe eines Anwendungsfalles) wird in /1/ ge- 
geben. 


Anwendungsbereich von SYSDFV 
wit Hilfe des Programmpäaketes SYSDFV können 


- Systeme von quasilinearen parabolischen Differentialglei- 
chungen 2. Ordnung in einer Ortsvariablen, 
- nichtlineare Zwei-Punkt-Randwertaufgaben 
gelöst werden. (Für halblineare bzw. lineare Gleichungen 
parabolischen Typs stehen spezielle Algorithmen zur Verfügung) 
SYSDFV ermöglicht die Behandlung einfacher kombinierter Mo- 
delle, die Durchführung von Modellsimulationen wird unter- 
stützt. Schnittstellen für eine Arbeit im interaktiven Be- 
trieb sina vorhanden. An der Ausfüllung dieser Schnittstellen 
sowie an der Schaffung von Bausteinen. zur Behandlung von lo- 
dellgleichungen in zwei Ortsvariablen wird gegenwärtig. gear- 
beitet. 
Las Programmpaket wurde bisher zur Simulation von chemischen 
Rohrreaktoren eingesetzt. &Es kann zur simulation vieler Pro- 
zesse verwendet werden, in denen: Diffusion, Konvektion, Reak- 
tion eine Rolle spielen (Wärmeleitungs- unä Verbrennungsvor- 
gänge, chemische und biöchemische Reaktionen usw.). 
Aurzcharakteristik von SYSDrV 
Las Spektrum der Anforderungen an Software zur numerischen 
Lösung von partiellen Differentialgleichungen ist sehr breit. 
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Dies resultiert zum einen aus der recht umfangreichen und 
nicht unkomplizierten Theorie und Numerik partieller Diffe- 
rentialgleichungen, zum anderen aber auch aus dem größer 
werdenden Kreis derer, die mit unterschiedlichsten Kennt- 
nissen und mit unterschiedlichsten technischen Vorsusset- 
zungen partielle Differentialgleichungen lösen wollen bzw. 
miissen. Die Wünsche gehen dabei von der "einfachen! Lösung 
einer Modellgleichung bis zu umfangreichen liodellsimulatio- 
nen. SYSDFV versucht diesem breiten Anwendungsspektrum ent- 
gegen zu kommen. Dies wird Gurch eine streng modulure Struk- 
tur und durch die Schaffung verschiedener Nutzungsebenen zu 
erreichen versucht. 

1. Autzungsebene: Konzipiert für einen 'ungeschulten' Nutzer, 
der ein 'Standsrdproblem' lösen will. 

2. Nutzungsebene: Konzipiert für einen 'etwas qualifizierte- 
ren' Nutzer, der Probleme zu lösen hat, die nicht der 
Standardform entsprechen (z.B. einfache kombinierte lo- 
delle), der einen Dialog mit dem Lösungsverfahren führen 
will oder der spezielle Modellsimulationen durchzuführen 
hat. 

3. Nutzungsebene: Konzipiert für einen '"Fachmann', der mit 
Hilfe von SYSDFV-Programmbausteinen neue numerische Ver- 
fahren implementieren will. 

Den Kern von SYSDFV bilden die Steuerprogramme, die so kon- 

zipiert sind, daß sie auch als Grundgerüst für weitere Soft- 

ware-Entwicklungen. genutzt werden können. Die Steuerprogramme 
können sowohl über speziell auf SYSDFY zugeschnittenen als 
auch über 'extern' entstandenen Programmbausteinen operieren. 

SYSDFV kann charakterisiert werden als ein Frogrammpaket, das 

bestimmte Eigenschaften eines Simulationssystens und einer 

Fachsprache besitzt und das seine qualitative und quantita- 

tive Erweiterung unterstützt. 


Datenorganisation 
Die Bereitstellung der Eingabedaten erfolgt in einer speziel- 


len Eingabesprache, die 'fingsbeeinheit ist vom Anwender frei 
wählbar (Standerd: Lochkartenleser). Alle Frogramnsteuerpara- 
meter besitzen Standardwerte, es müssen nur die Paraneter 

eingegeben werden, deren Wert verändert werden soll (Verwen- 
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dung der NAMELIST-Dateien in FORTRAN IV). Die Datenausgabe 
erfolgt mit Hilfe spezieller Unterprogramme, die Ausgabe- 
einheit ist vom Anwender frei wählbar (Standard: Drucker). 
SYSDRV stellt Bausteine zur Ausgabe zur Verfügung, der kin- 
satz anwenderspezifischer Ausgabeprogramme wird unterstützt. 
lhoduln zur Dateneingabe. über ein Terminal werden gegenwärtig 
erarbeitet, sie lehnen sich an das oben erwähnte Konzept an., 
Auch eine Datenübermittlung an das Terminal wird ermöglicht. 


Aufbau von SYSLiEV 
SYSLFV besteht aus einer Anzahl von Programmbausteinen (Sub- 
routinen), die in einem bestimmten Verhältnis zueinander ste- 
hen. Die Übergabe -der Programmsteuerung an SYSDFV erfolgt 
‘durch einen Unterprogrammaufruf. Der Anwender kann hierfür, 
entsprechend den Nutzungsebenen, unter verschiedenen Unter- 
programmen wählen. Diese unterscheiden sich durah' 
- den Service, der dem Anwender geboten wird, 
- die Anpassungsfähigkeit an spezielle Aufgabenstellungen, 
- die benötigten Ressourcen an Speicherplatz äls auch an 
Rechanzeit, 
- den Umfang an Kerintnissen, die der Anwender besitzen muß. 
Der Lösungsprozeß (einschließlich Datenein- und -ausgabe und 
eventueller Kommunikation mit dem Anwender) wird durch ein 
Steuerprogramm organisiert. Es wird entweder das Steuerpro- 
gramm selbst aufgerufen (hoher Freiheitsgrad und hoher Auf- 
wand für den Anwender) oder ein dem Steuerprogramm überge- 
ordnetes Programm, durch welches bestimmte Standardannahmen 
getroffen werden (geringerer Freiheitsgrad und geringerer 
Aufwand für den. Anwender). Auf der höchsten Nutzungsebene 
steht eine automatische Speicherplatzanforderung und -ver- 
waltung zur Verfügung. m 
Alle inhaltlich eigenständigen Funktionen (sowohl den Lösungs- 
prozeß als auch die Datenkommunikation betreffend) sind in 
getrennten, austauschbaren Programmbausteinen angesiedelt. 
Dadurch wird eine hohe Variabilität und Anpassungsfähigkeit 
erreicht. Durch einen speziellen Frogrammbaustein, der (bei 
der Lösung parebolischer Lifferentialgleichungen) nach jedem 
Integrationsschritt aufgerufen wird, ist sowohl ein "echter! 
als auch ein 'vorprogrammierter' Dialog mit dem Lösungsver- 
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fahren möglich. Mit seiner Hilfe kann vorgenommen werden: 

- eine Modifizierung oder ein Wechsel des Lösungsverfahrens, 

- eine Änderung von Programmsteuerparametern, 

- eine Woäifizierung der Modellgleichungen (Simulation von 
Steuer-, Regel- und Störvorgängen), 

- die Lösung von Nodellgleichungen, in denen z.B. partielle 
Differentialsleichungen mit gewöhnlichen Differentialglei- 
chungen oder mit algebraischen Gleichungen gekoppelt sind, 

- eine Arbeit mit adaptiven bDiskretisierungsnetzen, 

- ein Test auf Stationarität der Lösung usw. 

Für einfache Varianten des 'vorprogrammierten' Dialogs (die 

vorgesehenen Entscheidungen werden in herkömmlicher Weise 

vom Programm getroffen, ohne das der Anwender in den laufen- 
den Lösungsprozeß eingreifen kann) stehen Programmbausteine 
zur Verfügung, ebenso werden für einfache Varianten des. 

'techten'! Dialogs (der Anwender kann in den laufenden Lösungs- 

prozeß eingreifen) Standardbausteine bereitgestellt. 

Die Mehrzahl der oben aufgeführten Entscheldungsmöglichkeiten 

ist jedoch zu speziell, um sinnvoll in einem Standardbaustein 

untergebracht werden zu können, d.h. der Dialogbaustein wird 
in diesen Fällen vom Anwender selbst geschaffen. Dabei wird 
er von SYSDFV weitgehend unterstützt. Die Führung eines 'ech- 
ten! Dialogs kann in einfacher Weise in FORTRAN programmiert 
werden, die Kommunikation mit dem Terminal wird über Unter- 
programmaufrufe realisiert. Erste Unterprogramme hierfür (in 

Assembler realisiert) stehen rür die EDVA R21 (mit der Be- 

dieneinheit als Terminal) zur verfügung. Die Schaffung von 

Moduln für eine Dialogarbeit im Betriebssystem 0OS/ES unter 

Regie des TSO ist vorgesehen. 


Zur Ankopplung 'externer' Moduln an SYSDFV 
Zur Lösung vieler Probleme existiert bereits bewährte, lei- 


stungsfüähige software. Dies trifft z.B. auch auf das Gebiet 
der numerischen Lösung von gewöhnlichen Lifferentialgleichun- 
gen zu. Welche Vor- bzw. Nachteile bringt es, wenn versucht 
wird, unter Rückgriff auf vorhandene Programmbausteine reue. 
Software, z.B. zur Lösung von pärtiellen Differentialglei- 
chungen zu entwickeln ? Ein wesentlicher Vorteil ist in der 
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Möglichkeit zu sehen, die Entwicklungs- und Testzeit für 

des neue Softwaresystem entschieden zu verringern. Nachtei- 

lig dagegen ist, daß es im Zusammenwirken von unabhängig 

voneinander entstandenen Programmbausteinen unweigerlich 

'keibungsverluste' gibt: Es erhöht sich der Rechenzeit- und 

Speicherplatzbedarf gegenüber 'maßgeschneiderten' Systemen. 

Die Frage, ob nun der Vor- oder der Nachteil schwerer wiegt, 

kann nicht generell entschieden werden, sondern stets nur im 

Zusammenhang mit dem jeweiligen Anwendungsfall. Dabei soll- 

ten vor allem folgende Aspekte geprüft werden: 

- Rechtfertigt der durch 'Naßschneidern' nögliche Effektivi- 
täts- bzw. Qualitätsgewinn den erhöhten Entwicklungsauf- 
wand ? 

- Kann in der zur Verfügung stehenden Entwicklungszeit mit 
den vorhandenen Kapazitäten überhaupt eine höhere Qualität 
erreicht werden ? 

'Maßschneidern' führt in vielen Fällen zu einer guten Spezial- 

software, das kinbeziehen "externer' Moduln bzw. das Schaffen 

der Möglichkeit einer solchen Einbeziehung dagegen kann zu 
einer guten Standardsoftware führen. Bezieht man spezielle 

'externe' NModuln ein, so kann eine solche Standardsoftware 

sogar Spezialfälle lösen. Die Praxis zeigt, daß sowohl 'maß- 

geschneiderte' Software als auch (gute) Standardsoftware- be- 
nötigt wird. 

Natürlich führt das Lingliedern bewährter Programmbausteine 

in ein neues Softwarevorhaben nicht automatisch zu hoher Qua- 

lität. Diese steht und fällt mit'’dem Konzept dieses Software- 
vorhabens und mit der Art und Weise, wie die Eingliederung 
der entsprechenden Programmbausteine erfolgt. 

SYSDFV wird un geeigneten Stellen (z.B. zur Lösung von gewöhn- 

lichen Differentialgleichungssystemen) extern entwickelte 

Programmbausteine ankoppeln. Lafür gelten folgende Grundsätze: 

- has Systemkonzept wird unabhängig von den sich zur Ankopp- 
lusg anbietenden »oftwarebausteinen entwickelt. 

- kinsriffe in die anzukoppelnden. Softwarebausteine werden 
nicht vorgenommen, 

Beide Grundsätze sind sinnvoll: Die Programmbasis kann erwei- 

tert werden, ohne das Systemkonzept ändern zu müssen , die 
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eingebundenen Bausteine bleiben selbständig nutzbar. Zugleich 
werden ungeeignete Eingriffe in diese Bausteine vermieden. 
Die genannten Grundsätze machen defür aber i.a. den Einsatz 
von speziellen Kopplungsmoduln notwendig. Diese werden in 
Assembler ‘geschrieben und sorgen für einen reibungslosen In- 
formationsaustausch zwischen nichtkompatiblen Programmbau- 
steinen: Bestimmte Woduln werden nicht direkt aufgerufen, 
sondern über den Umweg eines 'Adapters'!. Damit wird auch ein 
Zusammenwirken von Bausteinen möglich, die in verschiedenen 
höheren Programmiersprachen realisiert sind. 


Programmiersprache 
Die Hauptbausteine von SYSDFV sind in FORTRAN IV geschrieben. 


Darüber hinaus werden für die Durchführung von Elementarope- 
rationen eine ganze Reihe von Assembler-lWoduln eingesetzt. 


Verwendete Lösungsbausteine 
Zur Lösung parabolischer Differentialgleichungen stehen ver- 


schiedene Differenzenverfahren (sowohl explizite als auch im- 
plizite) zur Verfügung. Die bisher vorhandenen Lösungsbaustei- 
ne sind speziell auf das Steuerprogramm zugeschnitten. Künftig 
sollen Verfahren hinzu kommen,. die auf der Semidiskretisierung 
beruhen. Dabei wird auf vorhandene Bausteine zur Lösung von 
gewöhnlichen Differentialgleichungssystemen zurückgegriffen 
werden. a 

Zur Lösung von Zwei-Punkt-Randwertproblemen wird auf vorhande- 
ne Ständardsoftware auf diesem Gebiet zugegriffen. 

SYSDFV gewährleistet einen reibungslosen Übergang vom Anfangs- 
Randwertproblem (parabolische Differentialgleichung) zum Rand- 
wertproblem und umgekehrt. 
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Fenske, Bernd und Meißler, Hans-Günter 


"Ein Konzept zum Einlesen eines Stromes von Lochbanddateien" 
1. Einleitung 


Auch an modernen ESER-Rechenanlagen hält der Bedarf zur Eingabe 
von LB-Dateien unvermindert an. Gründe dafür liegen einerseits 
in der nur zögernden Ablösung des Lochstreifens durch alterna- 
tive Datenträger, wie z. B. Magnetkassetten, bzw. durch eine 
Online-Datenerfassung über Terminals und andererseits in dem 
Fortbestehen der traditionellen Datenerfassung auf der Basis von 
Lochstreifengeräten. Demgegenüber steht die Tatsache, daß das 
Einlesen von LB-Dateien durch das Betriebssystem OS/ES nur sehr 
mangelhaft unterstützt wird. Neben einem hohen Bedienaufwand, 
der in sich bereits viele Fehlermöglichkeiten. birgt, wird die 
LB-Eingabe vor allem durch die Unsicherheit der Lesegeräte und 
durch einen unzureichenden Service des Betriebssystems in Fehler- 
sitüationen (Prüfbitfehler, Gerätefehler) behindert. Im folgen- 
den wird das Konzept des Programmes UHPTREAD vorgestellt, das am 
ORZ der MIU Halle entwickelt wurde, um diesen Problemen wirksam 
zu begegnen. 


2. ‚Funktionsprinzip von UHPTREAD 


Als Grundprinzip für die Arbeit von UHPTREAD wird eine Trennung 
der Dateieingabe von der eigentlichen Dateiverarbeitung ange- 
strebt. Alle LB-Dateien, die in einem bestimmten Zeitraum zur. 
Verarbeitung anfallen, werden mit einem Aufruf von UHPTREAD 
nacheinander eingelesen und für die spätere Verarbeitung auf 
DA-Datenträgern geeignet zwischengespeichert. UHPTREAD empfängt 
also eingabeseitig. einen Strom von LB-Dateien. Das Programm wird 
nicht, vom Nutzer selbst aufgerufen, sondern als Systemprogramn 
bei.Bedarf vom Bediener gestartet. Erst nachdem der Einlesevor- 
gang beendet ist, werden die Nutzerjobs vom Bediener freigegeben, 
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welche dann auf die zwischengespeicherten LB-Dateien zugrei- 


fen, Abbildung 1 zeigt die. Dateien bzw, externen Geräte, mit 
denen UHPTREAD arbeitet. 


Abb, 1 


(Bedienerverständigung) (Systemkatalog) 
AE SYSCTLG 


SYSIN . SYSUSER 
(Lochbandein- (Kontrollkenn- 
gabestronm) zeichen der 

| Nutzer) 


SYSDATA SYSPRINT 
(Lochband- (Protokoll und 
ausgabedateien) Fehlernachrichten) 


3, Erzeugunse der LB-Ausgabedateien 


Für jede eingelesene LB-Datei im Eingabestrom wird von UHPTREAD 
eine sequentielle LB-Ausgabedatei erzeugt. Diese wird vom Pro- 
gramm selbst im VTOC eines geeignet gewählten DA-Datenträgers 
mittels SVC 32 (ALLOCATE) eingerichtet und katalogisiert. Als 
Vorbild diente hier die Arbeitsweise des Systemeingabeprogramms 
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(vgl. DD-Anweisung IEFDATA beim Systemeingabeprogramm). Die LB- 
Ausgabedateien erhalten einen charakteristischen mehrstufigen 
Namen, anhand ‘dessen sie vom Nutzerjob zur Verarbeitung wieder 
aufgefunden werden können, Dieser Dateiname besteht aus drei 
Teilen 


DSN = SYSP.username. tapename 


Der erste Teil enthält ein festes Kennzeichen (SYSP). Durch den 
zweiten ‘Teil wird der jeweilige Nutzer identifiziert, der diese 
Datei verarbeiten will. Mit Hilfe einer Datei SYSUSER (vgl. 

Abb. 1) ist es möglich, über eine EXIT-Routine diese Nutzer- 
kennzeichen. zu überprüfen und dadurch abzusichern, daß sich un- 
terschiedliche: Nutzer nicht gegenseitig stören können. Es ist 

z. B. sinnvoll, an dieser Stelle den Namen des Jobs angeben zu 
lassen, der die LB-Ausgabedatei verarbeiten soll. Der dritte 
Teil kann vom Nutzer frei gewählt werden und dient ihm zur Iden- 
tifikation seiner jeweiligen Lochbanddatei. Die LB-Ausgabeda- 
teien haben ungeachtet ihres Namens grundsätzlich temporären 
Charakter. Das heißt, sie werden im allgemeinen nur bis zum Lauf 
des verarbeitenden Jobs aufgehoben. Wird beim Einrichten bereits 
eine gleichnamige Datei bzw. eine Katalogeintragung vorgefunden,; 
werden diese als verfallen gewertet und gelöscht. 


4. Struktur der LB-Eingabedateien 


Das Einlesen des Eingabestromes erfolgt durch UHPTREAD unab- 
hängig von der Struktur der einzelnen Dateien mit einer festen, 
großen Satzlänge. Die Aufspaltung in einzelne Sätze und die 
Konvertierung in den DKOI-Code erfolgt erst im Hauptspeicher 
durch das- Programm selbst. Dadurch ist die Möglichkeit einer 
gewissen Bearbeitung der Sätze gegeben. So kann z. Bs ‚das 
Satzformat ‘entsprechend wahlfreien Parametern der LB-Ausgabe- 
datei geändert werden, 

Die Strüktur der LB-Eingabedateien ist so vorgeschrieben, daß 
eine eindeutige Unterscheidung zu vorangehenden und nachfolgen- 
den Daten im Eingabestrom besteht. Zu diesem Zweck müssen die 
Dateien durch bestimmte, vom Lochbandcode abhängige Beginn- 

und Endemarkierungen, begrenzt sein. Alle Identifikationsanga- 
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ben und Parameter zur Beschreibung der Eingabedatei, zur Satz- 

bearbeitung und für die Ausgabedatei sind in einem speziel- 
len Kennsatz, der unmittelbar nach der Beginnmarkierung folgt, 

anzugeben. 


Abbildung 2 zeigt den Aufbau einer LB-Eingabedatei,. 


A) Lochbanddatei ohne Reihenfolgeprüfung der Lochstreifen: 


ul %| or |7| KENNSATZ DATENSÄTZE 
| DATENSÄTZE 


.oeso 
ee T m 
EHE 


B) Lochbanddatei mit Reihenfolgeprüfung der Lochstreifen: 


SSHESIH KENNSATZ H DATENSÄTZE . 
1z [RuRzKEImISarZ - DATENSÄTZE Bee 


-KURZKENNSATZ B DATENSÄTZE 2 | zor IE 


TZ - Trennzeichen, vom LB-Code abhängig 


Ss) 


NH 


5. Dienstleistungen des Programmes 


Folgende Dienstleistungen werden von UHPTREAD standardmäßig 
bzw. über Parameteranforderung im Kennsatz realisiert: 


- Katalogisieren der Ausgabedatei 
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- Prüfung auf Zulässigkeit zur Bearbeitung anhand der Nutzer- 
kennzeichen und einer Nutzerdatei 

- Satzformat F und U eingabeseitig 

- Automatische Satzendeerkennung (EORC) 

- Wahlweise Übersetzung in den DKOI-Code 
(es werden alle LB-Codes des 0S/ES unterstützt) 

- Unterschiedliche LB-Codes für Kennsatz und für Datensätze 
möglich 

- Ersetzen von fehlerhaften Zeichen (ungültig oder paritäts- 
falsch) durch ein Ungültigkeitszeichen 

- Umwandeln des Satzformates und der Satzlänge ausgabeseitig 
(zu lange Sätze werden abgeschnitten, zu kurze Sätze durch 
ein Füllzeichen aufgefüllt) 

- Ausblenden von Transportlochungen und Irrungszeichen 

- Ausblenden von Sätzen, die ein Satzirrungszeichen enthalten 

- Wahlweise Reihenfolgeprüfung (incl. Identitätsprüfung) der 
einzelnen Lochstreifen einer LB-Datei 

- Wahlweise Umwandlung von Kleinbuchstaben in Großbuchstaben 
bei der Übersetzung. in den DKOI-Code 

- Wahlweise Verarbeitung von Tabulatoren (max. bis Satzposition 
99) 

- Wahlweise Bereitstellung eines Fehlerbeschreibungswortes in 
jedem Satz (verlängert, verkürzt, ungültige Zeichen) 

- Standardmäßige Bereitstellung von Informationen über das Ein- 
lesen der Datei im Benutzervorsatz UHLI1 der Ausgabedatei 


Die Angaben im Kennsatz werden in Form von Stellungsparametern 
(Identifikationsangaben) und Kennwortparametern (wahlfreie 
Funktionen) gemacht. Die Abbildung 3 zeigt den Aufbau des 
Kennsatzes, 
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Abb. 3 Kennsatz einer LB-Datei 


ct Kennsatzcode 
SE Nutzerkennzeichen 
{,tapename} Lochbandname 
[‚number] Lochstreifennummer 
[,ıneur-{ryu}] Satzformat-Eingabe 
(,coDE=fa/B/C/F/I/K/L/M/N/P/Q/T/U}] Datencode 
[‚EORC=hh] Satzendekennzeichen 
[‚, BUFL=nonnn] Satzlänge-Eingabe 
[‚PELETEC=hR] Irrungszeichen 
[‚ DELETER=hh] Satzirrungszeichen 
[WRONGC=hh] Ungültigkeitszeichen 
[‚FILLc=hh] Füllzeichen 
[‚ change={ves/no}] Umwdlg. in Großbst. 
[‚TABc=hh] Tabulatorzeichen 
PTABSET=n1n2.. .nk]' Tabulatorpositionen 
[„RECFU={U/F/FB/RBS/v/vB/Vs/vVBS}]  Satzformat- Ausgabe 
[» LRECL=nnnnn] Satzlänge - Ausgabe 
(‚,BLKS12E=nnnon] Blocklänge - Ausgabe 
[„ERRORDw-{ves/no}] Fehlerbeschreibg.Wort 


1) - Identifikationsangaben 

2)- Beschreibung der Eingabedatei 

3)- Beschreibung der Satzaufbereitung 
4) - Beschreibung der Ausgabedatei 


6. Hilfsprogramme ’ 


Für die praktische Handhabung: von UHPTREAD im Rechenbetrieb 


existieren folgende Hilfsprogramme: 


1) 


2) 


3) 


4) 


SHSYSP - Löschen aller verfallenen LB-Ausgabedateien auf allen 


aufliegenden DA-Datenträgern 
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SFLBTEST - Test des Lochbandlesers auf Funktionstüchtigkeit 

SIPRINT - Erzeugen einer druckaufbereiteten Tabelle eines 
Lochbandcodes aus einer vorliegenden maschinenin- 
ternen Übersetzungstabelle 

UHLIREAD - UP. zum Einlesen des von UHPTREAD erzeugten UHLI 
für ASSEMBLER- und FORTRAN-HP. 

UHLIXPL - analog für PL1-HP. (normaler und optimierender 


Compiler) 


7. Praktische Erfahrungen bei der Anwendung von UHPTREAD 


UHPTREAD wird seit ca. 1 Y2 Jahren am ORZ’ der MLU mit Erfolg 
angewendet. Die damit verbundene Technologie der Lochbandein- 
gabe wurde für alle Nutzer zur Pflicht gemacht. Auch.große Pro- 
jekte, die auf Lochstreifenbasis arbeiten (LIS) sind auf diese 
Technologie übergegangen. Das Erlernen der Steuersprache von 
UHPTREAD erfordert zwar seitens der Nutzer einen geringen Auf- 
wand, der aber durch die damit verbundenen Dienstleistungen be- 
lohnt wird. Wesentlich wurde die Arbeit der Bediener ‘beim Einle- 
sen von LB-Dateien erleichtert, 

Der Funktionsumfang des Programms wird unterschiedlich genutzt. 
Häufig gebraucht werden die Umwandlung des Satzformates (ge- 
blockte Ausgabe), die Anwendung von Irrungs- und Satzirrungszei- 
chen, das Umwandeln von Klein- in Großbuchstaben und das Einle- 
sen (und Übersetzen) von fehlerbehafteten Lochbändern mit Er- 
setzen der ungültigen Zeichen. durch das Ungültigkeitszeichen, 
Sehr selten genutzt werden dagegen die Möglichkeiten der Be- 
reitstellung von Fehlerinformationen (UHL1, ERRORDW), die Ver- 
arbeitung von Tabulatoren und die Reihenfolgeprüfung der einzel- 
nen Lochstreifen einer LB-Datei. 

Aus dem praktischen Betrieb haben sich ferner folgende Wünsche 
für die Erweiterung des Funktionsumfangs von UHPTREAD ergeben, 


- Angabe einer beliebigen Menge von Irrungszeichen, die beim 
Einlesen der Daten auszublenden sind, statt wie bisher nur 
eines Irrungszeichens. 


= Verarbeitung eines Kontrollstreifens zur Prüfung der 
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Funktionssicherheit des LB-Lesers ‚(Integration der Funktion 
des Hilfsprogramms SFLBTEST in UHPTREAD selbst). 


- Vermittlung des Ausschnittes der SYSPRINT-Datei, der eine be- 
stimmte LB-Datei betrifft, an den verarbeitenden Job. Zur 
Zeit ist es nur möglich, das Protokoll von UHPTREAD bei der 


Rückgabe der Jobs vom Nutzer einsehen zu lassen. 


- Bequemes Einbringen von neuen (privaten) LB-Codes in die Ver- 
arbeitungsmoduln von UHPTREAD. Zur Zeit sind nur die im O0S/ES 
standardisierten LB-Codes vorhanden, 


An der Realisierung dieser Forderungen wird gegenwärtig gear- 
beitet,. 


Verfasser: Dipl.-Math. B. Fenske, Dipl.-Math. H.-G. Meißler 


Organisations- und Rechenzentrum der 
Martin-Luther-Universität Halle-Wittenberg 
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Klaembt, Egbert 
Schirmbacher, Peter 


Methodische Auswahl eines Datenauswertungssystens für den Ein- 
satz in einer Informationszentrale 


1. Einleitung 


Der Anteil der nichtschematischen Aufgaben innerhalb der Daten- 
verarbeitungsaufgaben auf. dem Gebiet der Leitungsunterstützung 
nimmt ständig zu. Nichtschematische Aufgaben sind nicht lang- 
fristig vorhersehbare, relativ einmalige und kurzfristig zu 1lö- 
sende Datenverarbeitungsaufgaben. Sie lassen sich durch die her- 
kömmliche Einzelprogrammierung nicht sinnvoll lösen. Einen 
gangberen Weg sehen wir in der Arbeit einer Informationszentrale, 
wobei die Nutzung von Datenauswertungs- und -verwaltungssystemen 
(DAVS) aus unserer Sicht eine Alternative zu Datenbanksystenen. 
sein kann. 

Unter einem DAVS verstehen wir eine einheitliche Datenbasis 

(ein Dateiensysten), für das vorgefertigte Programme und organi- 
satorische Regelungen zu ihrer Verwaltung existieren und ein De- 
tenauswertungssystem (DAS) zu ihrer Auswertung. Ein DAS ist ein 
System von Softwareprodukten mit möglichst hohem Automatisierungs-' 
grad, das zur Lösung nichtschematischer Aufgaben durch Auswer- 
tung einer einheitlichen Datenbasis eingesetzt wird. Das Spektrum 
der Softwareprodukte, die für bzw. als DAS im Sinne dieser allge- 
mein gehaltenen Definition genutzt werden können, ist recht um- 
fangreich. Dazu zählen u.E. Generatoren, .Universalprogramne, 
Nakrosysteme und Abfragesprachen, In der augenblicklichen Situa- 
tion stehen nachnutzbar vor allem Generatoren und interpretie- 
rende Systeme zur Verfügung, wobei deren Anzahl ständig zunimnt. 


Die Lösung nichtschematischer Aufgaben ohne Benutzung von DBS 
wird eine wichtige Rolle spielen, zumindest für’ die nächsten 
Jahre auf Grund der gegenwärtigen Datenbankproblematik, wie 
Prof. Schoppan auf dem 10. Kolloquium über Rechentechnik und Da- 
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tenverarbeitung in Magdeburg sagte, und, wie wir glauben, auch 
darüber hinaus in Abhängigkeit von den konkreten Einsatzbedin- 
gungen. Demzufolge gewinnen die Probleme des Einsatzes, der Be- 
wertung und der Auswahl von DAS an Bedeutung. Für jeden Nutzer, 
der seine nichtschematischen Aufgaben mit DAS lösen will, steht 
die Frage, welches konkrete DAS für seinen konkreten Anwendungs- 
fall das geeignetste ist. Es handelt sich hierbei um Fragen der 
Auswahl bzw. Selektion von Software. Damit sind wir bei einen 
allgemeinen Problem. Natürlich wurde Software seit langem in der 
einen oder anderen Weise ausgewählt, nur meist nicht sehr metho- 
disch. Die Entwicklung in der EDV geht aber zur verstärkten 
Nachnutzung von Software bzw. zur immer umfangreicheren Produk- 
tion von extra zur Nachnutzung hergestellten Software, damit 
auch zu umfangreicherer Softwareselektion. Wie auf anderen Gebie- 
ten der EDV (z.B. Programmierung, Entwurf) wurden hierzu in der 
Literatur der letzten Jahre eine Reihe von teilweise recht un- 
fangreichen Methoden vorgestellt, Uns geht es darum, die allge- 
meinen Methoden auf die Auswahl von DAS anzuwenden und eine auf 
diesen Fall. bezogene praktische unö relativ einfache. Variante 
erzugeben. Dafür sind einige Kompromisse notwendig, auf die wir 
an gegebenerStelle hinweisen. 


2. .Softwareselektion 


Zur Softwareselektion gehören eigentlich zwei Entscheidungen, 

Zum einen, ob Nachnutzung oder Eigenerstellung erfolgen soll, 

und zum anderen, wenn Nacknutzung die Auswahl aus mehreren Pro- 

dukten. Wir besckränken uns im weiteren auf die Entscheidung 

für Nachnutzung. Das scheint gerechtfertigt, da 

1. die Nechnutzung die vorzuzliehende Lösung ist, 

2. für unsere Auswahl genügend nachnutzbare Produkte zur Ver- 
Tügung stehen, 

3. die wenigsten Einrichtungen zur Eigenerstellung die kKöglich- 
keiten besitzen. 


Softwareselektion ist ein eubjektiver Bewertungeprozeß, zu des- 
sen Durckführurg geeignete Methoden herangezogen werden, Wesent- 
lich ist, daß Softwarebewertung immer von den konkreten Anforde- 
rungen des Anwenders abhängt, d.h. es geht nicht um das beste 
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Produkt schlechthin, sondern um das für den Anwendungsfall am 
besten geeignete. Die Softwareselektion umfaßt nech Frank /2/ 
folgende organisatorische Phasen: 
1. Bestimmung des Anforderungsprofile 
2. Sammlung von Produktinformationen und Feststellung des Lei- 
stungsprofils 
3. Produktvergleich und Auswahlentscheidung (Softwareselek- 
tion i.e.S.) 
4. Vertragsverhandlung, Implementierung, Effizienzprüfung 


Dabei: sind diese Fhasen nicht isoliert voneinander, vielmehr über- 
schneiden gie sich und laufen auch teilweise iterativ ab, Wir 
können hier nur schwerpunktmäßig und kurz auf die einzelnen Pha- 
sen eingehen. 


2.1. Bestimmung des Anforderungsprofils 


Das Anforderungsprofil ist die Grundlage für die Auswahlent- 
scheidung (sie ist übrigens auch Grundlage für die Eigenerstel- 
lung von Software), denn Versäumnisse; Fehler und Ungenauigkei- 
ten führen nahezu zwangsläufig zu nachteiligen Folgen beim Ein- 
satz der Software, In unserem Fall muß die Bestimmung des Anfor- 
derungsprofils letztlich zu einem konkreten auf die DAS-Auswahl- 
entscheidung zugeschnittenen Kriterienkatalog führen. Es ist 
jedoch in dieser Phase nicht ndwendig, den vollen Detaillisie- 
rungsgrad zu erreichen, denn die folgenden Phasen sollen in die 
Konkretisierung mit einfließen. Zum Inhalt des Anforderungs- 
profils für ein DAS gehören u.E. folgende Hauptpunkte: 

1. die erforderlichen Leistungen des DAS 

2. die Erfordernisse der vorhandenen Hard-/Software 

3. Handhabung und Kosten 


Sowohl unbedingt notwendig als auch wünschenswerte Eigenschaften 
sollten als solche gekennzeichnet werden. Vor der Angabe eines 
möglichen Kriterienkatalogs gehen wir noch auf die nächsten 
Phasen ein 
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2.2. Sammlung von Produktinformationen und Feststellung des 
Leistungsprofils 


Die Sammlung von Produktinformationen erfolgt günstig nicht erst 
nach der Bestimmung des Anforderungsprofils, sondern möglichst 
kontinuierlich, Es zeigt sich nämlich, daß das gar nicht so ein- 
fach ist, denn ein Katalog mit detaillierten Angaben über ange- 
botene Softwareprodukte existiert nicht, wäre aber wünschenswert. 
Man ist also angewiesen auf Informationen, die in Fachzeitschrif- 
ten, auf Kongressen, in Kundeninformationen, über die Projekt- 
und Programmzentrale, über das ZIID oder mündlich zu erhalten 
sind. Sobald mögliche Produkte und Hersteller bekannt sind, 
kommt man nahtlos zur Bestimmung des Leistungsprofils.. Der Inter- 
essent kann sich dabei auf Informationen des Herstellers, Erfah- 
rungen bisheriger Nutzer und eventuell auf Probeinstellationen 
stützen. Es scheint aber auf jeden Fall geraten, sowohl die vom 
Hersteller als auch die von bisherigen Nutzern erhaltenen Infor- 
mationen kritisch zu betrachten, 

Nach dem oben schon erwähnten Frank sollten vom Hersteller zu- 
mindest folgende Angaben vorliegen: 

- die Dokumentationsunterlagen 

- Software/Hardwareerfordernisse (auch für Installation) 

- verwendete Methoden 

- Datum der Erstanwendung 

- bisherige Anwender (Anzahl) 

- Erfahrungen beim Einsatz 

- Möglichkeiten der Einführungsunterstützung bzw. Schulung 

- Zusatzleistungen, geplante Ausbaustufen 

- Kosten 


Empfehlenswert ist sicher eine Probeinstallation, aber sie wird 
auf Grund des Aufwandes wohl nur selten möglich sein. Das Lei- 
stungsprofil ergibt sich aus allen verfügbaren Informationen. 
Als Beispiel möge die Kurzfassung des Leistungsprofils von ATLAS 
dienen, 


374 


Leistungsprofil ATLAS (I) (Kurzfassung) 


Hersteller:,LfA Berlin (A. Gustavs) 
Kurzcharakteristik: Programmgenerator, compilierend, aus Fra- 
genkatalog und Nützerexits generiertes PLA- 
Programn 
Anzahl der Installationen: ungefähr 50 
BS, Konfiguration: OS/ES, 1 WPS, 1 LKL, PD 
Schulungsmöglichkeit: bei WBA DVZ (1 Woche) 
Weiterentwicklung: ATLAS II (existiert) vorgesehen: interaktive 
Erstellung, DB-Anbindung 
Leistungen: 9 sequentielle Eingabedateien 
3 Ausgabedateien, 3 Listen 


Aus dem Vergleich von Anforderungsprofil mit den Leistungspro- 
filen erkennt man, welche Softwareprodukte für die Auswahl in 
Frage kommen. Das Vorhandensein geeigneter Software setzen wir 
voraus, ansoüsten bleibt nur Eigenerstellung oder Änderung der 
Anforderungen. Eigentlich ist an dieser Stelle zu klären, ob 
Eigenerstellung oder Nachnutzung sinnvoll ist, dieses soll aber, 
wie vorhin schon ausgeführt, zugunsten der Nachnutzung hier 
nicht diskutiert werden. Damit kommen wir. zum Kernstück der 
Softwareselektion. 


2.3. Auswahlentscheidung 


Gesucht ist in ünserem Fall im DAS Fi aus der Menge der zuläs- 
sigen DAS PasesesPn. +. Wir orientieren dabei auf ein einfach 
handbares Mat rixverfahren aus der Gruppe der mehrdimensionalen_ 
Auswahlverfahren. Allgemein formuliert ordnen die Matrixverfah- 
ren, die auf einem Kriterienkatalog basieren, jedem Software- 
produkt eine Zahl zu. Als bestgeeignetes Produkt wird das aus- 
gewählt, das die größte Zahl erhält. Diese Verfahren erfordern 
natürlich, daß jedem Produkt bzgl.’ jedes Kriteriums eine Zahl 
zugeordnet wird. Damit dies sinnvoll erfolgen kann, muß für die 
möglichen Nerknmale 'der Kriterien eine Vergleichsrelation vor- 
liegen._Das bedeutet, diese Verfahren setzen die Existenz von 
Verhältnisskalen (zumindest Intervallskalen) zur Bewertung der 
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Softwareprodukte bzgl. der Kriterien voraus. Nun ist diese Vor- 
aussetzung alles andere als selbstverständlich. Kriterienkata- 
loge sind in der EDV schon oft in Erscheinung getreten, vor allen 
bei der Bewertung von Datenbanksystemen (z.B. von Schubert/ 
Belke TU Dresden /1/). Dabei wird zur Bewertung der Merkmale 
innerhalb der Kriterien vielfach von Äquivalenzrelation bzw. 
Halbordnungsrelation ausgegangen, was dann bei der Auswahlent- 
scheidung zu Rangordnungsverfahren führen kann. Trotz unseres 
einfacheren Auswahlproblems spielen solche Kriterien ebenfalls 
eine Rolle. Wir können diese natürlich nicht einfach weglassen. 
Wir glauben aus praktischen Erwägungen heraus jedoch, daß es 
hier möglich ist, künstlich Verhältnisskalen einzuführen und mit 
kleinen Ergänzungen zum Matrixverfahren doch noch sinnvolle Er- 
gebnisse zu erhalten, 

Kriterien, die nicht skalierbar sind, können nicht in den Kata- 
log aufgenommen werden, 5 

Die Einführung von künstlichen Verhältnisskalen bedeutet z.B. 
für Ja-Nein-Kriterien, daß Nein Ö und Ja der höchste Wert zu- 
geordnet wird. 

Allgemein sollen die Kriterien weitestgehend unabhängig und ob- 
jektiv meßbar sein und der Kriterienkatalog alle relevanten Di- 
mensionen umfassen, aber nicht zu unfengreich sein. 


Unser Vorschlag für einen Kriterienkatalog hat folgendes Aus- 
sehen: 
Kriterienkatalog (DAS 


Kriteriengruppen Kriterien 
K1. Systemtechn. K1.1. HS-Bedarf 
Teil K1.2, BS 


K1.3. Laufzeitverhalten 
K1.4. Peripherie . 
K1.5. DAS-Bibliotheken 


K2. Handhabung K2,.1. Erlernbarkeit 
K2,2. Dokumentation 
K2, 3% Text 
K2.4. Automatisierungsgrad 
K2.5. organisatorische Flexibilität 


K3. Hersteller K3.1. Herstellerqualifikation 
K3.2. Anzahl der Installationen 
K3.3. Vertragsform 


K4. Systemkonzept, K4.1. DAS-Konzept 
K4.2. Sprachkonzept 
K4.3. Qualität 


K5. Koeten und Zusatz- K5.1. Kosten 
leistungen K5.2. Wartung 
K5.3. Einführungsunterstützung/Schulung 
K5.4. Weiterentwicklung 


K6. Leistungen K6.1. Eingabedateien 

K6.2. Anzahl der Eingzabedateien 

K6.3. Verknüpfungskonfort 

K6.4. Dateibeschreibung 

K6.5,. Ausgabedateien 

K6.6. Arithmetische Verknüpfungen 

K6.7. Gruppenbehandlung 

K6.8. Sortierung 

K6.9. Selektion 

K6. 10. Schlüsselverarbeitung 

K6.11. Druckaufbereitung 

K6.12. Vaarbeitungsarten 
Die Kriterien sind zu Kriteriengruppen zusammengefaßt. Die ein- 
zelnen Kriterien werden innerhelb der Kriteriengruppen und die 
Kriteriengruppen zueinander gewichtet, Das ergibt sich daraus, 
daß man volletändige Unabhängigkeit der Kriterien nicht errei- 
chen kann und die Kriteriengruppen bzw. die Kriterien innerhalb 
der Gruppen unterschiedlich für die Auswahl ine Gewicht fallen. 
Welche Kriterien in den Kriterienkatalog aufgenommen und wie 
die Gewichte verteilt werden, iet abhängig von den konkreten An- 
forderungen des Nutzers. Kriterien, die sich auf unverzichtbare 
Eigenschaften eines DAS aus Nutzersicht beziehen, werden extra 
gekennzeichnet, sie spielen später noch eine wichtige Rolle. Es 
isteicher sinnvoll für die Bewertung bzgl. eines Einzelkriteriuns, 
vorher schon Überlegungen,bzw. wie welche Merkmale bewertet wer- 


den sollen, zu fixieren (siehe Beispiel 1). 


Beispiel 1: Kriterien Einzelüberlegungen 
K6.1. Eingabe- Satzformate 
dateien Datenformate 

Einschränkungen 


Fells eine Frobeinstallation möglich war, ist die Bewertung wich- 
tiger Kriterien (z.B. Laufzeit, HS-Bedarf) auch als Ergebnis von 
eindimensionalen Verfahren (z.B. Benchnmarktest) zu erhalten. 
Dieser Prozeß der Auswahl und Gewichtung der Kriterien ecwie die 
Bewertung der Produkte bzgl. der Einzelkriterien ist der die Aus- 
wanl entscheidende Prozeß, deshalb eollte er äußerst sorgsam und 
sehr kritisch durchgeführt werden. 
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Als Zwischenergebnis erhalten wir eine Matrix, in der jede Zeile 
ein Kriterium, jede Spalte ein DAS und jedes Matrixelement die 
Bewertung eines DAS bzgl. eines Kriteriums darstellt. 

Im einfachen Beispiel 2 ist eine solche Matrix angegeben und wie 
das von uns gewählte Verfahren arbeitet, 


Beispiel 2: Gewichtestufenmethode 
Gestufte Gewichtun Noten (0.0-10.0) Bewertu hl 
Kriterien 6 . . rtungsza 
Produkte Produkte 
Stufe 1 Stufe 2 A B : A B 6 
K1.1. 10 3 8 10 30 100 
K1.2. 30 5 (6) 6 150 180 
K1.3s 60 7 z 2 420 120 
500 200 
K1 100 0.7 420 280 
K2.1s 20 ss 8 6 100 120 
K2.2, 20 7 9 5 140 100 
K2.3. 10 £ 2 3 = 30 
K2.4. 50 1 9 An Fr 
K2 0.3 180 210 
Gesamtbewertung 1 600 490 


Zuerst werden die besonders gekennzeichneten Kriterien, die un- 
verzichtbare Eigenschaften betreffen, behandelt. Hat ein DAS 

eine £ erhalten, fällt es aus dem weiteren Auswahlprozeß heraus. 
Deshalt werden sie auch als KO-Kriterien tezeichnet. Das benutzte 
‘Verfahren ist die Gewichtsstufenmethode (zweifache Gewichtung). 
Bei vorliegender Bewertungematrix ist nur noch eine einfache Rech- 
rung notwendig. Das DAS mit der höchsten Funktzahl ist das aus- 
gewählte (im Beispiel 2 das Frodukt A). 

Dem echließen sich noch einige Arbeiten, so bei knappen Ergebnie- 
sen eine Verfeinerumg , grafische Darstellungen (z.E. Spinne) und 
eine Effizienzprlüfung an, auf die wir hier nicht weiter eingehen 
wollen, die aber, wie auch die Vertragsverhandlung, das Auswahl- 
ergebnis noch beeinflussen können, 
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3. Schlußbemerkung 


Wir sind uns bewußt, daß das von uns hier angegebene Matrixver- 
fahren durchaus problematisch ist, vor allem hinsichtlich der 
Notwendigkeit von Verhältnisskalen. Unser Ziel bestand zum einen 
darin, auf Möglichkeit und zunehmende Notwendigkeit von metho- 
discher Softwareauswahl gerade auf diesem von uns für wichtig 
gehaltenen Gebiet hinzuweisen, und zum anderen darin, einen prak- 
tischen Vorschlag für eine relativ einfach handhabbare Selektion 
von DAS zu unterbreiten. Wir denken, daß eine gut gelungene Soft- 
wareselektion dem Nutzer einige Probleme ersparen kann. Wir .glau- 
ben auch, daß eine hreite Anwendung dieser Methoden zu Verbesse- 
rungen euf der Herstellerseite führen kann, in der besseren Be- 
reitstellung von für die Nutzer wichtigen. Produktinformationen 
und. letztlich in der Qualität der Softwareprodukte, 
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Elemente eines Plenungsdialoges im Fernmeldewesen 


1. Technologische und ökonomische Bedingungen des Reproduktions- 
prozesses im Fernmeldewesen als Basis einer Modellkonzeption 
zur Vorhersage des Bederfs an Ausrüstungen und Material 


-1e1. Bedingungen des technologischen Prozesses im Fernmeldewesen 


Eine Erhöhung des "Produktionsausstoßes" im Fernmeldewesen, der 
örtlich veränderten Nachricht, zur umfassenden Befriedigung der 
Nachrichtenverkehrsbedürfnisse der sozialistischen Gesellschaft 
ist nur möglich, wenn ein reibungsloses und proportionales Zusan- 
menspiel der wesentlichen technisch-technologischen Komponenten 
zur Realisierung des Fernmeldeverkehrs gesichert ist. Bezogen 

auf den bereitzustellenden Ausrüstungs- und katerialanteil bedeu- 
tet dies, die Sicherung einer proportionalen technologisch wohl 
begründeten Vorhersage des Bedarfs an Endeinrichtungen des Fern- 
sprech-, Fernschreibverkehrs und der Datenübertragung, der Ver- 
mittlungstschnik, der Übertragungstechnik und des Bedarfs an Ka- 
beln und Leitungen für den Ausbau und die Instandhaltung der 
Netze. Weitere zu berücksichtigende Merkmale sind die Struktur 
des Netzes mit den Komponenten Fernsprech-, Fernschreib-, Daten- 
Übertragungs-, Rundfunknetz und die existierenden Netzebenen ins- 
besondere die Unterteilung in Ortsnetz- und Weitnetzebene. 


Als Materialverbraucher tritt für den Ausbau des Fernmeldenetzes 
vorrangig die Produktionskapazität des Sprechstellenbaus und des 
Fernmeldebaus und für die Instandhaltung die des Technischen 
Dienstes in Erscheinung. 


1.2. Eine ökonomische Kausalkette für die Planung des Reproduk- 
tionsprozesses im Fernmeldewesen 


Jeder Entwurf eires Eodells zur Planung des Reproduktionrsprozes- 
ses im Fernmeldewesen wird bestimmt von den Flanungszielen, die 
nit dem Kodell unterstützt werden sollen und von der grundsätz- 
lichen "Nodellphilosophie", die der Autor zu Grunde legt. Ein 
Prognose- und Planungsmodell für den Bedarf an Ausrüstunger und 
Material im Fernmeldewesen muß insbesondere für mittel- und lang- 
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fristige Zeiträume, auf Grund der beschränkten apriori Kenntnisse 
über z.B. im Zeitraun von 5 Jahren zu realisierende Maßnahmen und 
Vorhaber und ihrer Konsequenzen für den Ausrüstungs- und Naterial- 
bedarf, aber auch auf Grund der real existierenden komplizierten 
Verflechtungen zwischen den Vorhaben verschiedener technologischer 
Bereiche, den Versuch unternehmen, objektiv vorhandene ökonomi- 
sche Kausalstrukturen zu implementieren. 


Damit kommt man zwangsläufig zu einem komplexen Gesamtmodell für 
den Reproduktionsprozeß, das es mehr oder weniger grob gestattet, 
ausgehend von den Zlelfornulierungen der Nachrichtenverkehrsbe- 
dürfnisse der Gesellschaft die Konsequenzen für die Grundfondsre- 
produktion, die Leistungsentwicklung im Fernmeldebau, Technischen 
Dienst und Sprechstellenbau sowie letztlich für den Bedarf an Aus- 
rüstungen und Material sichtbar zu machen. Die daraus resultieren- 
de/’und in-Abbildung 1 dargestellte Grundstruktur:für dem 'Modellan- 
satz beschreibt deri Planungsverlauf. 
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K, - Zuwachs an technologischen Kapazitäten des Fernnel- 
dewesens (Zuwachs an Hauptanschlüssen, Zuwachs an 
Anschlußnöglichkeiten in Vermittlungsstellen etc.) 


im Jahre t 
GF,„  - Notwendiger Zuwachs an technischen Grundfonds des 
Fernmeidewesens im Jahre t-r 
L}_n.g - Notwendige Produktionskapazitäten im Jahre t-r-e 
Nılnog 7” Relevanter Fedarf en Ausrüstungen und Material im 
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Abb. 1 
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2. Datenfonds, Methodenfonds und Technologig des Analyse- und 
Planungsinstrunentarluns für das Fernmeldewesen 


2.1. Daterfonde 


Die “&glichkeiten von Verfaliren zur Unterstützung des Analyse- 
und Planungsprozesses werden von Umfang und Konsistenz der zur 
Verfüzgng stehenden Datenfonds, von Jcr Algorithmenbasis, die 
zur Verarbeitung dieser Datenfonds verfügbar ist und ‘von der 
technclogischen Gestaltung des variahlen Zugriffs zu Daten- .und 
Wethodenfords bestirnt. 


Die Datenfonds des hier diskutierten Verfahrens bestehen aus 
Quartalsdaten für 4265 ‚Kennziffern des Reproäuktiorsprozesses 
Fernmeldewesen für die Bereiche Kapszitätsentwicklung, Grund- 
fondsertwicklung, Entwicklung produktiver Leistungen und die 
Entwicklung des NMaterial- und Ausrüstungsbedarfes. 


Diese 4265 Grundkennziffern sind für die 15 Bezirke und die DDR 
zum Teil bis in das Jahr 1960 zurückreichend verfügbar. Der Da- 
tenfonds ist für den Nutzer Über den Informetionskatalog des 
Verfahrens MWPLNO zugänglich, in dem jede Kennziffer durch fol- 
sende Grunddaten identifiziert ist. 

- Katalogbezeichnung der Kennziffer,’ 

Bezeichnung der Kennziffer nach Verfügung DP, 

Maßeilnkeit, 

. Datenquelle, 

Aktualisierungsdaten, 

Flandokument und 

Programm. 


Über die Katalogbezeichnung der Kennziffer hat der Nutzer sofort 
die Miglichkeit, die Kennziffer einen der Sachgebiete Kapazitä- 
ten, Grurdfonds, Leistungen oder Katerial- urd Ausrüstungsbedarf 
zuzuordnen. Die Eezeichnung der Kennziffer genäß einer Verfügung 
DP ermöglicht ihre Identifikation auf den Jeweiliger Arbeitsplatz 
des Frogestellers. Beide Bezeichnungen können wahlweise bei dem 
Ausdruck von Ergebnislisten- (Querschnittsübersichten, Zeitreihen- 
ausdrucke, Vörausberechnungen etc.) genutzt werden. In der Daten- 
quelle wird die geraue Eerkunft der Kennziffer aus einen EDVY 
des wWirtschaftszweiges bzw. aus manleller Datenerfassung einer 
statistischen Berichterstattung mitgeteilt. Aus den Aktunlisie- 
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rungsdaten ist die Periodizität der Aktualisierung der Kennziffer 
und die Verfügbarkeit des aktualisierten Datensatzes für den Nut- 
zer- ersichtlich. Die Angabe Plandokument weist die Zugehörigkeit 
einer Kennziffer aus einem Plandoküment des Wirtschaftszweiges 
aus. Über die Information Programm erhält der Nutzer die Informa- 
tionen, ob für die Kennziffer ein von Verfahren ererbeitetes Nor- 
mativ existiert. (Nornativkatalog), daß er die Möglichkeit hat, 
für die Kennziffer Zeitreihen bzw. Querschnittsdaten abzufordern 
und daß er Vorausberechnungen über die Entwicklung der Kennziffer 
‘erhalten kann. 


2.2. Nethodenfonds 


Die oben beschriebenen Datenfonds stellen den Ausgangspunkt für 
eine operative variable Problembearbeitung für unterschiedlichste 
Problerstellungen aus den vier Sachgebleten Kapazitätsentwicklung, 
Grundfondsentwicklung, Entwicklung produktiver Leistungen und 
Katerial- und Ausrüstungsbedarf dar. 


Zur Bearbeitung der Informationen stehen die-arithmetischen Ope- 
rationen zur Verfügung, die‘-es unmittelbar ermöglichen, aus den 
Grundkennziffern Quotienten, Aggregationen, prozentuale Anteile 
etc. abzuleiten. Die variable Zusammenstellung von verschiedenen 
Kennziffern in tabellarischer Form (Matrixkonzept) wird durch die 
statistischen Verfahren des zur Anwendung kommenden PP- STATISTIK 
gewährleistet, Die Ermittlung von-Richtwerten -für Planungsgrößen 
wird durch die Möglichkeiten zur Zeitreihenmodellierung, dem'Nor- 
mativkatalog und Simulationsmodellen auf ökonometrischer Basis 
unterstützt.. Damit enthält die Algorithmenbasis umfassende Nig- 
a ulm und Analyseprobleme zu bearbeiten. 


2.3. Technologie 


Die Effizienz eires Infornationssystens wird wesentlich äurch ‘die 
projektierten technologischen Lösungen zu’ seiner Handhabüng be- 
sticmt. Ein ‚Informationssyuten, das über die Befriedigung: reiner 
Auskünfte aus Inforrationsfonds tLlnaus geht und das eine ‘variable 
Troblembearbeitung auf der Basis von Datenfonds zum Ziele. hat, 

kann nur in begrenztem Umfange automatisiert werden. Daraus er- 
‚gibt sich, daß einerseits eir- Zwischenglied "zwischen Informations- 
system und nicht speziell ausgebildetem Nutzer existieren muß 
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(Anwendergruppe für Informationssystem), andererseits muß eine un- 
mittelbore redundanzarme Reaktionsfähigkeit auf die Nutzerbedürf- 
nisse möglich sein, 


Für die praktische Anwendung des mit dem Verfahren MY/PLNO bereit- 
gestellten Informationssystems fungiert eine Anwendergruppe als 
Bindeglied zwischen Nutzer und Informationssystem. Die Verständi- 
gungsbasis zwischen Anwendergruppe und Nutzer zur Problembearbei- 
tung bildet der Informationskatalog des Informationssystems. Eine 
direkt für die selbständige Anwendung durch den Nutzer verfügbare 
Leistung des Informationssystems ist der Normativkatalog des Ver- 
fahrens. 


Der Anwendergruppe stehen zur Problembearbeitung eine Reihe von 
standardisierten Lösungen zur Vorausberechnung und Analyse. das 
PP STATISTIK/OS mit seiner Algorithmenbasis und für einen Teil 
der Pröblembearbeitung die Dialogtechnologie des DSL-Wonitor- 
systems zur Verfügung. Weitere Projektierungsarteiten konzentrie- 
ren sich vor allem auf die direkte Verfügbarmachung der Daten- 
fonds für den Nutzer Über Bildschirm (Ankunftssysten) und der 
weiteren Dialogisierung der Problembearbeitung durch die Anwen- 
dergruppe. 


Verfasser: 

Dr. Wolfram Wittig 

ORZ der Deutschen Post 
1179 Berlin 
Waldpromenade West 4 
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DIE ANWENDUNG DER DATENBANKTECHNIK UND DES MENSCH-MASCHI- 
NE-DIALOGS IN DER ZENTRALEN STAATLICHEN PLANUNG VON KUBA 


Jorge Barrera 


Zusammenfassung: 


Im August 1981 wurde das Einheitliche System der Planbe- 
arbeitung (ESPB) im Zentralen Rat für die Planung (Juce- 
plan) der Republik Kuba eingeführt. 

Es wird die erste Version dieses Systems und seine Aufga- 
ben und Funktionen beschrieben. 
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Im August 1981 wurde das Einheitliche System der Planbear- 
beitung (ESPB) im Zentralen Rat für die Planung (JUCEPLAN) 
der Republik Kuba eingeführt. 

Die erete Version des ESPB ist ein System, das mit Hilfe 
der Rechentechnik die Erfassung, Speicherung, Verarbeitung 
und Ausgabe der Daten sichert, die durch die Mitarbeiter 
des JUCEPLAN für die Ausarbeitung der Volksnirtschaftsplä- 
ne und für die Kontrolle ihrer Durchführung benutzt werden. 
Das ESPB besteht aus einer Menge funktioneller und versor- 
gender Teilsysteme, die die verechiedenen Aufgaben mittels 
einer koordinierten Arbeitsweise lösen. 

Die funktionellen Teilsysteme sind für die Ausführung (oder 
für die Unterstützung) der Planaufgaben, die im ESPB inte- 
griert sind, zuständig. Um ihre Arbeit durchführen zu kön- 
nen, stützen sie sich auf die versorgenden Teilsysteme. Für 
die erste Version des ESPB wurden 17 funktionelle Teilsyste- 
me entwickelt, die den Planungsabteilungen enteprechen. 
Versorgende Tatleysteme sind die folgenden: 

- das methodologische Teilsyetenm, 

‘- das informationelle Teilsystenm, 

= das mathematische Teilsystem, 

- das technische Teilsystem, 

- das technologische Teilsystem. 

Im Rahmen des vorliegenden Beitrages nerden die allgemeinen 
Mittel der informationellen und der mathematischen versor- 
genden Teilsystene vorgestellt. 


1. Das informationelle versorgende Teileystem 


Die informationelle Versorgung des ESPB hat das Ziel, die 
Informationen, die für die Ausarbeitung des Volkswirtschafts- 
planes benötigt werden, zu untersuchen und dis Regeln ihrer 
Strukturierung, Organisation und Modifikation für einen ef- 
fektiveren Einsatz der elektronischen Datenverarbeitung zu 
definieren. Unter informationellen Gesichtepunkten ist der 
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Volkswirtschaftsplan in letzter Instanz aus Plankennziffern, 
Klaseifikatoren und Nomenklataoren zusammengesetzt. 

Eins Plankennziffer ist eine Größe, die das zu erwartände 
oder reale quantitative Verhalten eines Aspektes des volks- 
wirtechaftlichen Reproduktionsprozesses darstellt. Im ESPB 
werden die Plankennziffern in primäre und berechnete Kenn- 
ziffern klassifiziert, wobei die primären Kennziffern die 
aind, die von den Planern direkt an das System gegeben wer- 
den, und dio berechneten Kennziffern die eind, die vom Sy- 
stem automatisch ausgearbeitet werden. 

Nach ihrer Zusammensetzung kann man eins Kennziffer folgen- 
dermaßen definieren: 


KZF r {9: r} 
wobei 


g = die quantitative Größe der Kennziffer ist: 

m = die Maßeinheit darstellt und. 

Ia {1,. 15, ..., 103 ale die Menge der Elemente (Kodex) 
definiert wird, die für die Identifizierung der Kenn- 
ziffer nötig sind. Jedes "i" wird Identifikator go- 
nannt. 

Als Beispiel einer Plankennziffer kann das Folgende ange- 

sehen werden: Die Warenproduktion von Zement im Zweig der 

Baumaterialienindustrie des Ministeriuns für Baumesen wird 

im Jahre 1985 5000000 Tonnen betragen (der gegebene Wert 

soll nur als Beispiel interpretiert werden). Die Komponen- 

ten dieser Kennziffer sind folgende: 


g = 5000000, 
m = Tonnen, 
1, = Warenproduktion, 


1, = Zement, 

1, = Ministerium für Bauwesen, 

1, ® Zweige der Baumaterialienindustrie, 
1,» Jahr 1985. 


387 


Die Untersuchung der verschiedenen Identifikatoren (1), die 
für die Darstellung der Plankennziffern benutzt nerden, ist 
einer der Hauptaspekte der informationellen Versorgung des 
ESPB. Die Identifikatoren sind auf den Domänen (Koordina- 
ten) von Zeit und Raum (geographischer, dkonomischer, orga- 
nisatorischer usw.) definiert. Ihre Gesamtheit erlaubt die 
genaue Identifizierung jeder Plankennziffer. Die für die 
Identifizierung der in der Planung der Volksnirtschaft bo- 
nutzten Kennziffern der notwendigen Domänen bilden die Klas- 
eifikatoren des ESPB. 

Die Klassifikatoren werden als kodifizierte Listen der Ob- 
jektklasse dargestellt. Nach ihrer Zusammensetzung kann ein 
Klassifikator wie folgt definiert werden: 


KLA = {k, A} 


wobei: 
k = ein Kode ist, der den Schlüssel jedes Elementes des 
Klaseifikators darstellt und 


A .{a,, Sys 0.0 an) die Attribute jedes Elomentes des 
Klassifikators sind. Ale Attribute können Beschreibun- 
gen, Maßeinheiten, verbindliche Kode oder Zahlenwerte 
vorkommen. 

Einer der wichtigsten Klassifikatoren in ESPB ist der Klas- 

seifikator für "Ökonomische Messungen”, der den dkonomischen 

“Inhalt jeder Kennziffer zum Ausdruck bringt. Dieser Klas- 
sifikator wird bei jeder Kennziffer benutzt (explizit oder 
implizit) und definiert den Bkonomischen Aspekt des Repro- 
duktionsprozesses, den man messen will (siehe 1, "Waren- 
produktion" im vorherigen Beispiel). Andere wichtige Klas- 
eifikatoren des ESPB sind "Ökonomische Aktivitäten” (in 
denen alle Produkte und Leistungen, die in JECEPLAN geplant 
werden, enthalten sind), "Wirtschaftsleitende Organe”, 

"Sektoren und Zweige", "Bezirke", "Investitionen" usw, 

Ein anderer Begriff, der für die informationelle Vorsor- 
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gung des ESPB von Bedeutung ist, ist der Begriff des Nomen- 
klators. Die Nomenklatoren dienen der ausführlichen oder 
funktionellen Definition der Menge der Kennziffern, die in 
einem bestimmten Plandokument enthalten sein sollen. 

Nach ihrer Zusammensetzung kann ein Nomenklator folgender- 
neise definiert werden: 


Nom = {K, AS, 


wobei: 

Ks ik4. kos “es; Ko} die zugehörigen Kode der Teilmenge 
der Identifikatoren I (I = i1,. IPTBEIIT) 1,3 ) der 
Kennziffern, deren Nomenklator zu definieren ist, dar- 
stellen. 

Wenn m = p, dann wird die Nomenklatur in ausführlicher 
Weise definiert, und wenn m>p, wird eie in funktionel- 
ler Weise definiert. 

Weiterhin spricht man von einem einfachen Nomenklator, 
wenn p = '1,und wenn p >1, sagt men, daß der Nomenkla- 
tor sei zusammengesetzt. 

Au Ia,. Br 0 an} stellt wie bei den Klassifikatoren 
eine Menge von Attributen dar. 


Um dis Größe, Kompliziertheit und Variabilität der Struk- 
tur der Datonbasis von JUCEPLAN beherrschen zu können, 
nurden für die Datenbank des ESPB drei vereinfachte Daten- 
modelle benutzt, welche die vorher definierten Datonarten 
widerspiegeln können und als Klassifikatoren, aktualisier- 
bare Belege und Ergebnistabellen bezeichnet werden. 

Diese Datenmodelle nurden ausgehend von den Erfahrungen 
des Hauptrechenzentrums des GOSPLAN der UdSSR und der Ar- 
beiten von E, F,. Codt über das relationale Datenmodell 
entwickelt /5/6/9/. 

Das Datenmodell der Klassifikatoren schließt die Klassifi- 
katoren und die Nomenklatoren des ESPB eins sie werden ale 
Liste von Relationen (oder n-tupeln) dargestellt, wo jede 
Domäne entweder ein Kode oder ein Attribut sein kann. Un 
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tiefer in dio Begriffe Relation, Domäne und n-tupel einzu- 
dringen, kann man die bibliografiechen Referenzen /5/, /7/ .. 
/ı1/ und /12/ benutzen. 

Das Datenmodell der aktualisierbaren Belege entspricht den 
primären Kennziffern, auch wenn eventuell einige berechne- 
te Kannziffern, die während des Erfassungsprozesses erhal- 
ten werden, hier auch eingeschlossen aind. 

Diesas Datennodall oonie das der Ergebnistabellen hat das 
Ziel, den Benutzer (Planer) eine Daretellung der Daten an- 
zubieten, die den normalen Plandaokunenten, die eeit jeher 
benutzt werden, so ähnlich wia möglich ist. Diese Darstel- 
lung beruht auf der bekannten tabellarischen Einordnung 
der Daten in Spalten und Zeilen (siehe die Ähnlichkeit 

mit dom Relationshbegriff). 

Bei den autonatisierbaren Belegen wird die Information in 
3 Ebonen eingeteilt: Belog, Seite, Zeilo. 

Die Belege sind Übereinstimmande Gruppierungen von Plan- 
kennziffern, die eine sinheitlicha oder kompatibele Struk- 
tur haben. 

Die Soiten sind Teilmengen von Belagen, die nicht mehr als 
20 Zoilen und eine von Beleg abhängige Anzahl von Spalten 
umfassen. In einer Soilte können die Kennziffern aines oder 
nehrerer gleichwartiger Identifikatoren enthalten sein, 
Diego Identifikatoren worden im oberen Teil der Seite (Kopf 
der Seite) gesetzt und logische Idantifikatoren des Kopfes 
(LIK) genannt, während der Rest der Identifikatoren, die 
normalerweise für ‚jode Konnziffer verschieden und desne- 
gen in jeder Zeile zu schreiben eind, als logische Iden- 
tifikatoren der Zeile (LIZ) bezeichnet werden, Die Zeilen 
eind Mengen von Identifikatoren und quantitativen Werten, 
wobei jeder einer Spalte entspricht, die im Datenmodell in 
horizontaler Weise oingesetzt werden. 

Das ESPB sichert dem Benutzer den Zugriff zu einer. Seite 
eines gegebenen Belege im Dialogbetrieb und über die Sta- 
pslverarbeitung den Zugriff zu einer Gruppa von Seiten oder 


zum ganzen Beleg. 

"Das Datenmodell der Ergebnistabellen entspricht den Ergeb- 
nisformationen des ESPB, die aus primären und berechneten 
Konnziffern zusammengesetzt sind. Ihre Struktur ist der der 
Bolege ähnlich, mit dem einzigen Unterschied, daß eu keine 
Grenze für die Anzahl der Zeilen, die zu einer Seite. gehö- 
ren, gibt. 

Wie boi den Belegen existieren auch im Datenmodell der Er- 
gabnistabellen die Begriffe "logischer Identifikator dee 
Kopfes” und "logischer Identifikator der Zeilen” (LIZ). 
Das ESPB sichert dem Benutzer den Zugriff zu der ganzen 
Ergebnistabelle, zu den Zeilen, dis den gleichen LIK haben 
(Seite bei den Ergebnistabellen) und zu jeder einzelnen 
Zeilo. 

l 
2. Dae mathomatioch versorgende Teilsysten 


Das mathematisch. versorgende Teilsyetem ist dazu bestimnt, 
dio nötigen: Programmittol für die Lösung der Aufgaben des 
ESPB in den EDV-Anlagen auszuarbeiten und weiterzuentrik- 
koln. 

Un die rechentochniochen Funktionen der Erfabsung, Berech- 
nung und Ausgabe somohl im Stapelbetrieb ale auch in ei- 
nem Mansch-Maschine-Dialog bei den unterschiedlichen Mork- 
malen jedes der funktionellen Teilsysteme zu eichern, ‚var 
es nötig, bei den Elementen der Datenfonda somie bei den 
rechentechnischen Verarboitungsverfahren, im Rahmen der 
informationellen bzu. mathematischen versorgenden Teilsy- 
steme eine Menge von Gestaltungsmaßnahnen zu treffen. Wo- 
raus eine allgemeine standardisierte Gestaltung der Haupt- 
‘alemente beider Teilsystome erzielt nurde. 

Diose allgemeine standardisierte Gastaltung wird in jedem 
einzelnen Fall durch Parameter pr&özisiert, was die rationel- 
le Beherrschung der großen Varicbilität der Struktur der 
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Daten und der Verarbeitungsverfahren ermöglicht. Die Para- 
meter bestimmen demzufolge sowohl die präzise Lage der Da- 
ten als auch die Einzelheiten der auf sie anzunendenden 
Verarbeitungavorfahren. Die allgemeine mathematische Vor- 
eorgung des ESPB ist aus einer Menge von Algorithmen, Pro- 
grammen und Hinweisen zusammengesetzt, die mittels einoe 
Parameterkomplexes den Hauptanteil (etna 90 %) der rechen- 
technischen Funktionon der Erfassung, Berechnung und Aus- 
gabe jedes funktionellen Teilsystems und insbesondere al- 
le die Verarbeitungen, die direkt mit den gespeicherten 
Daten zu tun haben, durchführt, 

Für die technische Realisierung des ESPB wurden außer der 
Grobbeschreibung der Nutzerfreundlichkeit der allgemeinen 
mathomatischen Versorgung für die verschiedenen Benutzer 
(Planer, Organisatoren, Programmierer und EDV-Batriebsepe- 
zialiston) folgende Anforderungen an diess Mittel gestellt: 


- Existenz eines Öinzigen’' gespeicherten Datenfonds (ale Da- 


tanbank), der gleichzeitig in einem Mensch-Maschine-Dialog 


und im Stapelbetrieb betrieben werden kann und der die 
notwendige Sicherheits- und Schutzmaßnahmen besitzt; 


- Modulare Gestaltung der Progremnkomplexe mit .dem Ziol, 
eine progressive Roalisierung und Inbetriebnahme sonie 
nachfolgende Wartungen zu erleichtern; 


- Optimale Besetzung der verfügbaren technischen Mittel. 


Ausgehend von diesen Anforderungen und unter Beachtung so- 
wohl der Ergebnisse der früheren Untersuchungen und For- 
schungen sonie der Charakteristiken der etaastlichen zentra- 
len Planung als auch der verfügbaren technischen Versorgung 
wurde die allgemeine mathematische Versorgung des ESPB in 
die folgenden Programmkomplexe eingeteilt: 


- Datenbonkbetriebesystem (DBBS), 
- Wiederherstellungsprozedur, 
- Kohärenzkontrolle, 


- Wartung der .Dateien; 

- Parametererfassung, 

- Stapelerfassung; 

- Zurückgeninnung, 

- Laden der Tabellen, 
-!Ausladen der Tabellen, 
- Taobellengonerator, 

- System für den Dialog durch die Bildschirmgeräto (SDB), 
- Einflußdirektor. 


Das Hauptmorkmal der gewählten allgemeinen Gestaltung ist 
das Betrachten aller dieser Programmkomplexe ala sequen- 
tielles zusammenlaufondos System /2/, /4/, da. sie nährend 
ihrer Laufzeit in voerechiedenen Bereichen des Speichere 
untergebracht werden. Die Kommunikation zwischen all die- 
sen Programmkomplexen wird bei der Annendung der Technik 
des "Postfaches”, die bei dem BORLAEHNSYELON SIRIS-III der 
IRA-50 vorhanden ist, erreicht. 11/* 


Das Prinzip dieser Technik beruht darauf, daß ein Programm 
eine oder mehrere Datenzonen (Postfächer) erklären kann, 
wo es Nachrichten von anderen Programmen, die in anderen 
Speicherregionen arbeiten, erhalten kann. Die erhaltenen 
Nachrichten bilden eine Werteschlange und werden nach den 
Bedürfnissen dee betreffenden Programms abgearbeitet. Je- 
des im Betrieb stehende Programm kann Nachrichten zu den 
Postfächern, die von anderen Regionen erklärt wurden, 
schicken. 
Die Existenz eines einzigen Programmkomploxes für das Be- 
treiben der Datenbank sonie die Anwendung der Postfächer- 
technik sichern die Erlangung der Anforderungen über den 
+ Dem Verfasser ist keine andere Anwendung der Postfach- 
technik als Grundlage der Bestimmung der Architektur 
eines Datenbankbetriebssystems bekannt, obwohl die Er- 


gebnisse gezeigt haben, daß diese Tochnik gerade für 
die Datenbankproblematik sehr geeignet ist. 
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öleichzeitigen Stapel- und Dialogbetrieb der Datenbank und 
über die modulare Gestaltung der Programmkomplexe, die an 
die allgemeine mathematische Versorgung des ESPB gestellt 
wurden. 

Außer den vorganannten Programmkomplexen, die zu allgemei- 
nen mathematischen Versorgung das ESPB gehören, echlioßt 
diesas Teilsystem auch folgende typischen mathematischen 
Versorgungenittel ein: 


"= Programmkonplexe: für die Zusammenfassung und Berechnung 
von .Kennziffern im Stapelbetrieb; 


- Routine für dio Zusammenfassung und Berechnung der Echt- 
zeit, 


In weiteren werden die Hauptmerkmale dieser Programmkomplexe 
beschriebon. - 

Das Datenbankbätrioehseystem (DBBS) ist ein Progranmkomplex, 
da* die Datenübertragung zmiächen dem Dateikomplex, in dem 
physiach die Daten der Datenbank des ESPB gespeichert sind, 
und den restlichen Progrannkonplexen durchführt. Die rest- 
lichen Progrommkonplexe werden auf diese Welse von der Not- 
nondigkeit, die physische Struktur der gespeicherten Datan 
zu konnan, befreit. 


Die Gosamtheit der Daten des ESPB wird in drei Hauptdateien 
öingöteilt, zwei von ihnen haben eine undefinierte Organi- 
sation und eine hat eine sequontielle Organisation. Aus 
diesen Dateien kann jedes Programn die elementare Datenein- 
heit: 


- Das Attribut bei den Klaseifikatoren, 
- Die Seite bei den aktualisierbaren Bolagen, 
- Die Zeile bei den Ergebnistabollen 


sogar in direktem Zugriff, als auch sequentiell nach ver- 
schiedenen Kriterien, unter Benutzung der Postfachtechnik 
durch das DBBS zurückgeninnen oder schreiben. 

Dafür wurde eine Datenmanipulationssprache (DMS) entnickelt, 
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welche aus etwa 60 Anneisungen zusammengesetzt. iet und die 
von jadem Programmkomplex für die Zurückgewinnung und das 
Schreiben dar Daten aus bzw. in der Datenbank über die 
Postfächer benutzt wird. Weiterhin existiert eine COBOL- 
Schnittstelle, die es erlaubt, die DMS auch in den in die- 
ser Sprache geschrieben, nicht ellgemeinen Programmen, zu 
benutzen. 

Die Speicherung der Klassifikatoren und Nomenklatoren wur- 
de in einer nichttraditionollen Weise gestaltet. In der 
Datenverarbeitungspraxie ist es üblich, alle die Attribu- 
te, die zu einem Objekt innerhalb einer Objektklasse gohßd- 
ren, in einem physischen Satz zusammenzustellen. Diese 
physische Organisation der Klassifikatoren ist aber nur of- 
fektiv für den direkten Zugriff aller Attribute eines Ob- 
jektse, was besondere in der Aktualisierung der Klassifike- 
toren gebraucht wird, und für die sequentielle völlige Zu- 
rückgerinnung aller Attribute einer Gruppe von Objekten in- 
nerhalb einer Objektklasse, vias für die Liston der Klassi- 
fikatoren oder für andere, im allgemeinen nicht von den 
Kennziffern abhängige Gesantverarbeitungen aller Attribu- 
ta einer Gruppe von Objekten ist. 

Die Klassifikatoren und Nomenklatoren haben aber ale eines 
ihrer Merkmale, daß eie eine große Stabilität aufneisen, 
und daß deswegen ihre Aktualisierungsrate in der Praxis 
vernachlässigt werden kann. Das Liston der. Klassifikatoren 
oder ihre gesamte Verarbeitung wird auch sehr selten ge- 
macht. Die häufigste Benutzung der Klassifikatoren findet 
während der Ausarbeitung der Ergebnistabellen statt. Die- 
ser Prozeß kann aber so organisiert werden (programmäßig), 
daß die Zurückgewinnung der notwendigen Attribute .nicht 
für jede Zeile, sondern auf einmal für eine Gruppe von 
Zeilen (zun Beispiel für eine Seite) durchgeführt wird. 


Die gewählte physische Organisation der Klassifikatoren, 
die ‘das Ziel verfolgt, diese letzte Art der Arbeit nit 
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den Klassifikatoren zu optimieren, setzt ‚als physische 
Speicherungseinheit die Liste aller Werte jedes Attribu- 
tes, d. h. alle die Realisierungen aines und desselben 
Attributes fest. In der Sprache des relationellen Daten- 
modelle könnte man es so ausdrücken, deß die ganze Domb- 
ne die Speicherungseinheit darstellt, d. h. daß die Re- 
lationen nicht nach Tupeln, sondern nach Domänen ge- 
speichert worden. 

Die Beziehungen zwischen den Werten verschiedener Attri- 
bute, die zu einem und demselben Objekt gehören, werden 
durch eine "Verwirklichungsnunner gesichert”, dio der or- 
dinalen Stelle jedes Wertes in der zugehörigen Lioto ent- 
spricht. Für alle zum selben Objekt gehörenden Attribut- 
werte ist oieo dieselbe. Dia Vorwirklichungenumner der Ob- 
jekte eines. Klassifikators werden nach der im System chro- 
nologischen Eintrittefolge ausgewiesen. Das Konplenent 
dieser in undefinierter Weise organisiorten Datei ist ei- 
ne Direktzugriffsdatei, in der ein Satz für jeden Schlüs- 
sel eines Klassifikators oder Nomenklators exietiort und 
die dio zugehörige Verwirklichungenunner enthält. Das er- 
möglicht den Zugriff zur vorhor erklärten undefinierten 
Datei, um den Wert einse Attributes beim - Vorhandensein 

dos Wertes dee zugehörigen Schlüssels zu kennen. Die prak- 
tischn Anwendung dieser Speicherungsform hat bewiesen, daß 
sich die Anzahl der physischen Zugriffe zu den Dateien für 
die Vorbereitung einer Tabelle bis um das 30-fache im Var- 
gleich mit der traditionellen Methode vernindert. 

Die physische Speicherungsform der aktualiserbaren Balege 
im Datenfonds wurde unter Berücksichtigung der Antnortge- 
schnindigkeit, der Flüssigkeit der Verarbeitungsprozesse 
und der Sicherheit der Daten entschieden. Dis physische 
Speicherungseinheit ist die Seite eines Beleges in einer- 
Datei mit undefinierter Organisationsform,. Die Eingänge 
und Ausgänge in den bzw. aus dem Datenfonds werden demzu- 
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folge immer über ganze Seiten durchgeführt. Die Adresse 
jeder Seite wird dabei in einor Datei mit direktem Zu- 
griff eingeschrieben. Für einen Beleg kann es bis 20 
Sätze dieser Datei gaben, deren Schlüssel die Belegnum- 
mer und der Satznummer (von 1 bis 20) ist. Jeder Satz 

hat 250' Adreßverneise, die die Lage des ersten Bytes der 
Seite in der undefinierten Datei enthält. Mit dieser Or- 
ganisation kann man eine Seite in folgender Weise zurück- 
gewinnen, wenn man ihre Nummer kennt. 
= Man errechnet die Satznummner der Datei, die die Adrass- 

vorweise onthält, durch die Formel: 


Satznumner = Settgnnunmor + 1 


- Man sucht in der Datei mit direktem Zugriff den Satz 
nit dem Schlüssel Belegnumner - Satznumaner 


- Mit dem Rest der Division Seitennummer/250 bekommt man 
im vorher gelesenen Satz die Adresse der-Seite. 


Darüber hinaus gibt es bei den aktualisierbaren Belegen 
eine dritte Datei mit direktem Zugriff, die den Schlüssel 
der: Belegnummer "logischer Idenfikator des Kopfes” (LIK) 
hat. Sie enthält die verschiedenen Seitennunnern, die zum 
gegebenen LIK gehören, so daß auch der Zugriff zu einer 
bestimmten Information möglich ist, wenn ihre physische 
Seitennummer nicht bekannt ist. 

Bei den Ergebnistabellen ist die physische Speicherungs- 
einheit die Zeile einer Tabelle. Alle Zeilen aller Tabel- 
len werden in einer index-sequentiellen Datei gespeichert. 
Um die Redundanz des Kodes zu vermindern und etwas Platz 
Zu gewinnen, gibt es im Dateikomplex eine zueite Datei 
für die Ergebnistabellen, die den Schlüssel Tabellennun- 
mer -— LIK hat, und die eine laufende Nummer für jeden 
Satz besitzt. Auf diese Weise niird der Schlüssel der er- 
eten Datei folgendermaßen zusammengesetzt: 


- laufende Numner :{von zweiter Datei angegeben), 
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= logischer Identifikator der Zeile (LIZ), 


Der Zugriff zu den in der Datenbank gespeicherten Informa- 
tionen wird für die Mitarbeiter das JUCEPLAN, die den Zu- 
stand von "Abonenten” erhalten haben, begrenzt. Das Betrei- 
ben des Systeme durch die Bildschirme fördert die Durch- 
führung von automatischen Schutzmaßnahmen, die bei dem ESPB 
in zwei Ebenen gegliedert sind: 


- die Oberprüfung des Zustandes dos Benutzens als Abonent 
des Systems am Anfang einer Sitzung, 


- die Überprüfung des Rechtes des Abonenten, zu einer be- 
etimmten Information in der Datenbank zuzugreifen. 


Boide Schutzuaßnahnen werden vom DBBS mit Hilfe einer in- 
dexsequentiell organisierten Datei, die Abonentendirektö- 
rium genannt nird, automatisch durchgeführt. 

Das DBBS eichert weiterhin die Datenbank vor Unfällen oder 
Operationsfehlern, die die gespeicherten Informationen in 
unerwünschter Weise verändern oder zerstören. Das erreicht 
man mit Hilfe einer auf Magnetband gespeicherten Datei, 
die alle die Datenbank verändernden Anrufe zun DBBS ent- 
hält, und die laufend nach der Durchführung der zugehö- 
rigen Operationen von DBBS geschrieben wird. 

Die Wisderherstellungsprozedur ist dafür bestimmt, im Fal- 
le des Vorkommens irgend eines Umstandes, der die Daten- 
bank zerstört, den Inhalt desselben bis zu dem der Zer- 
etörung vorhergehenden Moment wiederherzustellen. 

Alle Anneisungsfolgen an das DBBS bei Benutzung der DMS 
benötigen eine Eröffnungsanweisung vor ihrer Durchführung 
und eine Endanweisung nach der vollen richtigen Beendigung 
des Verarbeitungsschrittes. Diesa Eröffnungs- und Endan- 
weisungen werden auch in die Sicherheitsdatei geschrieben. 
Die Wiederheretellungseprozedur analysiert die Sichsrheits- 
datei dee DBBS und befiehlt dem System. die Anneisungen zu 
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wiederholen, dic den Inhalt der Datonbank geändert haben 
und die oinwandfrei beendet wurden. Dieser Prozeß voll- 
zieht eich natürlich auf der Grundlage der Kopie der De- 
tenbank eigenen Datei durchgeführten Wiederherstellung 

der Anfangsbedingungen. = 

Auf diese Weise wird gesichert, daß im Falle der Zerstd- 
rung der Datenbank maximal die Aktualisierungen der in 
diesem Moment in den Bildschirmen stehenden Seiten verlo- 
rengehen. 

Die Kohärenzkontrolle hat als Ziel, die automatische Übor- 
prüfung der Richtigkeit der Adreßvorkettungen und sonstigen 
Serviceinformationen zu ermöglichen, die zwischen den bzw. 
in den die Datenbank bildenden physischen Dateien vorhan- 
den sind. 

Weiterhin werden dabei dio notnendigen Informationen go- 
geben, um im Falle der Entstehung irgend eines Fehlors 
denselben analysieren zu können. Bei der Benutzung der De- 
tenbankbetriebssystenme treten oftmals Inkohärenzen in oder 
zwischen den physischen Dateien auf, die zum DBBS gehören. 
Diese Tatsache hat als Ursache, daß die Durchführung einer 
Schreibanneisung, die zum DBBS gegeben nird, noraalerneise 
in mehrere physische Schreibbefehle übersetzt wird, die 
alla vollständig durchgeführt: werden müssen, da es, nenn 
es nicht so geschieht, ohne weiteres vorkommen kann, daß 
die Zugriffsalgorithmen nicht mehr richtig arbeiten. 

Ein einfaches Beispiel. für diese Tatsache findet man bei 
den Dateien mit index-sequentieller Organisation, bei de- 
rien, wonn ein neuor Satz hinzugefügt wird, es nötig ist, 
den Satz in der Datei zu schreiben und die Indextabellen 
und Adreßverkettungen zu den anderen Sätzen zu pflegen. 
Wenn es irgondeine Unterbrechung der Arbeit der EDV-Anla- 
ge (Ausfall der Energie, Zusammenbruch des Operations- 
systems usn.) während der Zeitspanne, die für die Durch- 
führung der oben genannten physischen Schreibbefehle Vor- 
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kommt, ist es selbstverständlich, daß die Datei in einem 
unbenutzbarsn Zustand bleibt. 

Da bei den DBBS noch komplexere Verkettungen in oder 
zwiechen den Dateien nötig eind, nimmt die für die völ- 
lige Durchführung einer den DBBS gegebenen Schreibannei- 
eung nötige Zeitspanne und damit auch die Wahrscheinlich- 
keit einer Zerstörung der Datenbank bei einer Arbeitsun- 
terbrechung der EDV-Anlage zu. 

Die Wartung der Dateien "ist zu machen, wenn die unter der 
Kontrolle des vom Hersteller der EDV-Anlage glieferten 
Dateibetriebssyetene befindlichen physischen Dateien, we- 
gen ähnlicher Ursachen wie die vorher erklärten, zerstört 
nerdon. 

In diesen Fall nird oftmals dio Unregelmäßigkeit nicht 
gleich durch die Kohärenzkontrolle entdeckt, sondern in 
einem Moment, in dem die Wioderharstellung der Datenbank 
durch die übliche vorher erklärte Prozedur sehr aufwendig 
näro. 

Bei der Ausnutzung der in der Datenbank vorhandenen Re- 
dundanz ist der Programmkomplex für die Wartung der Da- 
teien in der Lage, alle Verzeichnisdateien der Klassifi- 
katoren und der ektualisierbaren Belege völlig neu zu 
schreiben, die einer solchen Zerstörung ausgesetzt waren. 
Da sie eine Diroktzugriffsorganisation haben, läßt sich 
von den Dateien ausgehen, die die Informationen als sol- 
che haben, die Dank ihrer undefinierten Organisation 
nicht vom Dateibotriebseystem zerstört werden können, 

Die anderen- Dateien des DBBS, die eine index-sequentielle 
Organisation haben, werden mit Hilfe von Nutzerhilfspro- 
gramnen, die vom Hersteller der EDV-Anlage geliefert wer- 
den, gewartet. 

Die Parametererfassung erfüllt folgende Aufgaben: 


- Syntaktische Kontrolle aller Paranster, die sonohl. für 
die Beschreibung der Geographie der verschiedenen Da- 
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tenarten als auch für die Bestimmung der auf sie anzunen- 
denden standardisiorten Prozeduren in die Datenbank sin- 
geführt werden. 


Die Übersetzung des externen (Quell-) Formates der Para- 
meter auf ein internes (Objekt-) Format, das für die 

Vereinfachung des Betriebes der Programme gestaltet nur- 
de, die die mathematische allgemeine Versorgung des ESPB 


bilden. 


- Ausgabe von Listen über die in der Datenbank geladenen 
Quellparameter. 


Die Stapelerfassung der aktualisierbaren Belege wird mit- 
tele einer Programmbtte, die folgende Funktionen umfaßt, 
durchgeführt: e 


- physische Kontrolle der Eingangsdaten, 

- Aktualisierung der Belege, 

- logische Kontrolle der aktualisierten Daten, 

- Laden der aktualisierten Belege in der Datenbank, 

= Listen des Abbildungsprotokolls der in der Datenbank 
geladenen Daten. 


Die Aktualisierung der Belege wird mittels der klassischen 
Funktionen Einfügen, Verändern, Löschen durchgeführt, wo- 
bei das Einfügen immer nach Zeilen, das Verändern nach 
Zeilen oder Zeilen/Spalten und das Löschen nach Zeilen 
oder Spalten durchgeführt werden kann. 

Die Einteilung in physische und logische Kontrollen der 
Eingangsdaton entspricht der Auffassung, daß das Rechen- 
zentrum nur dafür verantnortlich ist, die exakte Obertre- 
gung der auf Belegen enthaltenen Daten auf maschinenles- 
bare Datenträger durchzuführen, nas durch die physische 
Kontrolle gesichert wird, während die Bonutzer (Planer) 
für den Inhalt der Belege verantwortlich sind, deren syn- 
taktische Fehler durch die logischen Kontrollen gezeigt 
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werden. /3/ 
Außer den vorgenannten Funktionen_sichert dieser Programn- 
komplex, daß die Zeiler, die zu einem logischen Identifi- 
kator des Kopfes gehören, immer rechtmäßig innerhalb der 
Seiten, zu denen sie gehören, sortiert bleiben. 
Die Listen des Abbildungsprotokolle der in der Datenbank 
geladenen Daten können wahlweise nur für die Seiten, die 
modifiziert waren, oder für den ganzen Beleg gedruckt wor- 
den. 
Dieser Programmkomplex wird auch für das Anfangsladen ei- 
nes Beleges, der nicht auf Papier, sondern auf irgend ei- 
nen anderen maschinenlssbaren Datenträger kommt sonie für 
die Ermittlung der Abbildungsprotokolle der Saiten, die 
mit Hilfe der Bildschirme in einem Mensch-Maschine-Dialog 
modifiziert waren, benutzt. Die letztgenannte Funktion 
wird durch die Verarbeitung der Sicherhaitsdatei erreicht. 
I} 


Die Stepelerfassung der Klassifikatoren umfaßt folgende 
Funktionen: 


- Kontrolle der Eingangsdaten, 

- Aktualisiorung der zugehörigen Dateien, 

- Ausdruck der durchgeführten Aktualisierungen, 
- Listen der Klassifikatoren. 


Die Zurückgeminnung der Daten, die in der Datenbank ge- 
speichert eind, ermöglicht, relationale Dateien zu bekon- 
men, ausgehend von den Belegen, den Klassifikatoren und 
Nomenklatoren. R 
Bei der ersten Version.des ESPB nurde dieser Programmkon- 
plex in einer minimalen Vereion eingeführt, die nur die 
natürliche Vereinigung /5/ zuischen einem Beleg und den 
Klassifikatoren und Nomenklatoren löst. Für zukünftige 
Versionen ist vorgesehen, diesem Progrannkomplex schritt- 
neise soweit zu ermeitern, daß er den Umfang der rela- 
tionalen Algebra erreicht, 
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Doa-LedeatvonsErönbrnirtabeiller, Natönundio: Funktionen der 
Voreirigungıallbirsborschrioten Datatgnyi.dig: ‚ale Tabelle 
geledea:wordon;scollen;:4hrs Unfornung:quanDatenbanklade- 
formst»undıdosteigbntlitchät Ledersdnädia,Datonbank. 


Daa :Ausledeim: vomErschnistrbellehyfühut; ‚zuri:umgekehrten 
Unfornurgsyg.th hvomDatenbankfornatszua: "Hornat der be- 
rechraten: Dotslen;undıächrieibt: disjontearnchonden Datei- 
emauf.ı Mignetbünderse, 


Der: TobsllbneerersternletsoiniPrögannnkenplex\, der die Auf- 
hebeb hat; allii.didi Fregen;n diainitl,der;Einsotzung der Da- 
ten: aufudenusoltäh:undieiti dem: ELHfi0Jon: dar konstanten 
Torter undade: Artributreizuitunshebsayizu@idsen, un, aus- 
gchendison:demberechnsten: Datei em;Ergabnistabellen mit 
det::notwendidtanQuUslitätänuszudrückenvija.. 


D83:SystenmfürideA:DI3logrdvrch:JiazBildichirmgeräte (SDB 
des»ESPS"orlabbt>den:Rlänssr;,»dircktsmit-der'Datenbank zu 
arbeiten;ndurchsdidterfüllungrfolgendarzfyunktionen: 


- Aktüoläblerungnder.Klädgifikstoranzüssz; 

- AktlaliblerungidgesBolsege;,s, 

- Anschensdersänider:Doterbahkrgespoichanten ‚Ergebnista- 
beildhan. 


Andororonätsterlnübzhuuchtätdsersprögrannkoaplex dem Ple- 
nersihransporsönlätkens Schlüssel; (Abotzatachlüssel) zu 
ändorn;nuonnnorevorautotzidaß«ör>jonandamvanderen bekannt 
istst o 
Did!Hapsnerkraloldidses“Rrögrannkorgloxsa.:sind folgende: 
- AntsandurigrdorsAutobatentheorso!.fGriktieiisostaltung der 
verschinderien;Rrögransodulon,.n/13X: 3X... 
- AnäandungnyonofrägesAntnörtprozodursn-(geschlossener 
Dinlog)t}” 


$ elchendboztat9737 
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mit der Signalisierung der möglichen” "Äntworten "als ‚Grund- 
gedanken für dio Gestaltung des Dinlogeı 


- Möglichkeit der Auswahl zwischen verschiedenen, Vörslönen 
des Dialogs mit dem Ziel, die durchzuführenden Anschläge 
für eine bestimmte Arbeit minisieren Zu" könnens” 


- Anwendung der Wiederbenutzungetechnik (gleichzeitige Be- 
nutzung ein und desselben Programms für. ‚mehrere: Aufga- . 
ben) für die Realisierung der Progremmodulens , 


- Gestaltung und Einführung einer besonderen Prozedur für: 
die dynamische Nutzung des Operationsspeichere ; mit 90- 
kundären Speicherungen auf Magnetplatten. ‚mit..dem Ziel, 
den notwendigen Operationsepeicher .zu mininieren, :bei 
der Benutzung des Umfangsunterschiedes ;zwischen..den. 
Reaktionezeiten des Menschen und der. Maschine (nach. den 
Untersuchungen in JUCEPLAN liegt dieser: Unterschied. in“ 
der Größe 10 : 1). nz 


Die maximale Reaktionszeit dos Dialoge. bei den elementa- 
ren Funktionen übersteigt nicht 4 Sekunden, mas, nach den. 
peychologischen Forschungen 'eine optimale zeit iet ‚(eieha 


Fü 


+ von: Selte 96 


Im allgemeinen gibt os zwei Möglichkeiten; "üm' -8inen :Mensch- 

Maschine-Dialog zu gestalten: 

. offener Dialog, wo der Benutzer seine Wünsche in Form von. 
Programmen (auch wenn sie sehr einfach sind) formuliert. 
Bei dieser Art von Dialogen unterscheidet. man-weiter zwi-. 
echen pfozeduralen und nichtprozedurälen Sprachen (die 
relationale Algebra bzw. das relationale Kalkül. sind. Bei- 
spiele von Sprachen für die Zurückgewinnung von ‚Daten, 
die offen funktionieren können. 

«. geschlossener Dialog, vo der Benutzer an Hand von festge- 
Testen 'Frage-Antwort-Prozeduren und.den'zugehörigen: Menue 
ihre Wünsche allmählich präzisiert, bis sie von: der EDV- 
Anlage durchgeführt werden können. 

für Fachkader, die nicht in der EDV spezialisiert sind, ist 

die zweite-Variante vorteilhafter, da mit ihr:die‘ ‘Ansprüche 

an dan EDV-Kenntnissen der Kader sehr niedrig gehalten wer- 

den können und somit das psychologische Hindernis, das im- 

mer bei dor Anwendung der EDV zu finden ist, leicht bowäl- 

tigt werden kann.- 


AD4- 
/ 

/8/ und /10/. Außer den vorhergenannten Funktionen sendet, 
wenn es gewünscht wird, das SDB zum Einflußdirektor .den 
ursprünglichen Wert und den 'neuen Wert jeder primären Plan- 
kennziffer, die modifiziert wird mit dem Ziel, die zuge- 
hörigen, datoenbankgeladenen Ergebnistabellen im Echtzeit- 
betrieb zu aktualisieren. 


Der Einflüußdirektor ist eine Schnittstelle zwischen dem 
SDB und dem DBBS einerseits und dem Routinekomplex ando- 
rerseits, der die Aktualisierung der in der Datenbank ge- 
ladenen Ergebnistabellen ‚im Echtzeitbetrieb sichert, aus- 
gehend von den Modifikationen der primären Plankennziffern, 
die durch die Bildschirme durchgeführt wurden» 

Im weiteren werden die Hauptmerkmale der typischen mathe- 
matischen. versorgenden Mittel beschrieben, die in der er- 
sten Version des ESPB eingeschlosssn sind. 


Die Stapelberechnung und =aggreglierung der Plankennziffern 
kann man im ESPB durch einen parametrisierten Programn- 


komplex, der folgende Funktionen eichort, durchführen: 


‘= arithmetische Operationen zwischen den zu dem selben 
Satz gehörenden Daten; 


- arithmetische Operationen zwischen zu verschiedenen 
Sätzen gehörenden Daten; 


- Bildung neuer Sätze durch die Aggregierung oder andere 
erithmetische Berechnungen zwischen den Daten, die zu 
den zu verarbeitenden Sätzen gehören, 


Bei dieeom Programmkomplex haben sonohl die Ergebnisda- 
teien als auch die Eingangsdateien eine Geographie mit 
deriselben Prinzipien, die für dio zurückgewonnenen Da- 
teien benutzt werden. Auf diess Weise nird eine große 
Flexibilität für die Gestaltung der Berechnungen, für 
die Benutzung des Tabellengenerators oder für das Laden 
und Ausladen der Ergebnistabellen in der Datenbank er-: 
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reicht. 

Wenn die Möglichkeiten, dis von diesan Mitteln geboten 
warden, nicht für die Lösung oinar bestimmten Aufgabe 
ausreichen, oder wonn aus Effoktivitätsgründen die Ba- 
nutzung einös anderen Alg&#thmus empfohlen wird, konn 
men dis Urwandiung der zurückgewonnenen Datoien in bs- 
rechnaten Dateien mittels jepozifischor mathonatischer 
Versorgungsnitrel durchführen, 

Die Berechnung und Äggragierung in Echtzeit dar Ergebnis- 
taebellon viärd, wie vorher gesagt wurde, mittsls alnes 
‚Routinsekomploxes erreicht, der vom Syetem für don Dialog 
durch den Einflußdirekter den ursprünglichen und nsuen 
Wert joder pririöroen modifiziorten Plankennziffer bekomnt. 
In Abhängigkeit vom aktualisierten Buleg ruft der Ein- 
flußdirektor die zugehörige Routino auf, die dan "Ein- 
fluß” dor Verändorung der modifizierten prinären Kann- 
ziffor auf die in don Ergebnistabellon gespeicherten 
Kennziffern, die damit zu tun-haben, Zorechnet, 

Diooo Prozedur sichert, daß sich dio aktunliecrbaren Bo-- 
loge und dio Ergsbnistabellen auf Dauer Guf denselben Ak- 
tuslisierungsenivoau in der Detonbank stehen, was oinor- 
seite die Qualität bostimmter Planungsaufgaben um ein 
Vielfaches erhöht und andererseits die EDV-Anlegenzeit 
für die tägliche Staepelberechnung der Tabellen spart. 

Für dio detaillierte Gestaltung und die Realisierung der 
allgemeinen mathematischen Versorgung wurden 480 Mathe- 
matiker-Monatoe vernendet. Die Anzahl der geschriebenen 
und Betrieb gesetzten Anweisungen beläuft sich auf 79076 
Befehle im IRIS-assembler (ASSIRIS) und auf 20825 Annei- 
sungen im COBOL. 
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Zur Parallelisierung von Datenverwaltung und -verarbeitung in 
Progre emen 


1. Einleitung 


Wissenschaftlich-technische Aufgabenstellungen, bei denen die 
zur formalen Beschreibung des könkreten Problems erforderlichen 
Daten einen solchen Unfang annehmen, daß sie im Hauptspeicher 
einer EDVA nicht gleichzeitig darstellbar sind, bilden aufgrund 
des hohen Leistungsvermögens von Informationsverarbeitungs- 
systemen heute keine Seltenheit mehr. Die im Verlaufe des 
Lösungsprozesses solcher Aufgabenklassen zu verarbeitenden und 
neu anfallenden Daten werden in einer Speicherhierarchie dar- 
gestellt, deren bekanntester Vertreter. der virtuelle Speicher 
(VS) ist /2/. Während jedoch die Verwaltung dieser zweistufigen 
Speicherhierarchie durch die VS-Steuerung problemunabhängig er- 
folgt, kann eine problemangepaßte Organisation der Speicher- 
hierarchie bel genauer Analyse von Problem- und Datenstrukturen 
zu einer effektiveren Gesamtlösung führen, wenngleich sich der 
Entwicklungsaufwand i. a. erhöht. 

Eine solche Aufgabenklasse ist beispielsweise die Behandlung 
.des allgemeinen Eigenwertproblems 


(A- ABX = 0 


für großdimensionlerte schwachbesetzte symmetrische Matrizen 
A und B, wofür an der Sektion Mathematik der TH Karl-Marx-Stadt 
ein Programmpaket entwickelt wurde /3/. Diese Aufgabenstellung 
ergibt sich u. a. aus der elastostatischen Berechnung von Bau- 
teilen mit Hilfe der Methode der finiten Elemente. 

In diesem Programmpaket ist eine problemorientierte Verwaltung 
der Speicherhierarchie enthalten, der das Konzept der abstrak- 
ten Datentypen zugrundellegt, wobei eine möglichst effektive 
Datenverwaltung durch Minimierung der Anzahl der Transfer- 
operationen und weitgehende Parallelisierung von Arithnetik 
und Transfer angestrebt wurde. 
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2. Problemorientierte Datenverwaltung 


Unter einer Datenverwaltung werden alle Funktionen und Prozesse 
verstanden, die unmittelbar verantwortlich sind für die Vergabe 
von Zugriffsrechten zu ausgewählten Daten an die Programmoduln. 
Dabei wächst der Anteil der Datenverwaltung am Gesamtlösungs- 
aufwand sehr rasch mit der Komplexität der zu verarbeitenden 
Datenstrukturen. Insbesondere gilt dies, wenn zu ihrer Verwal- 
tung die Organisation einer Speicherhierarchie erforderlich ist, 
Möglichst viele Details dieses Organisationsaufwandes für die 
Nutzer von Programmsystemen zu verdecken, ist eines der wesent- 
lichen Ziele bei der Konzeption von Datenverwaltungssystemen. 
Bei virtuellen Speichern wird dies durch eine problemunabhängige 
Unterteilung des (virtuellen) Speicherraumes in Seiten meist 
gleicher Iänge und einen in der VS-Steuerung fixierten Paging- 
Algorithmus erreicht, wobei eine ständige Speicherzugriffsüber- 
wachung erfolgt. Für den Nutzer unsichtbar, sorgt die VS- 
Steuerung stets für die Anwesenheit der aktuell benötigten 
Teilstrukturen (Seiten) im Realspeicher. Entscheidende Nachteile 
ergeben sich jedoch bezüglich der Programmnlaufzeiten bei einer 
zu freien Nutzung dieser Vorzüge eines virtuellen Speichers /7/. 
Eine willkürliche Unterteilung problemorientierter Datenstruk- 
turen in problemunabhängige Teilstrukturen führt i. a. zu einer 
sehr hohen Transferrate. Deshalb wird als Qualitätskriteriwm 
für Programme in virtuellen Speichern deren Iokalitätsverhalten 
herangezogen, d.h; die Fähigkeit der Algorithmen, während des 
Aufenthalts einer Seite im Realspeicher deren Informationsgehalt 
maximal zu nutzen, bzw. über möglichst lange Zeiträume jeweils 
nur zu einigen wenigen Seiten zuzugreifen. 

Daraus wird klar, daß für das Erreichen guter Iokalitätseigen- 
schaften die Art und Weise der: Abbildung problemorientierter 
Datenstrukturen auf die Seiten des VS und deren Berücksichti- 
gung in den Algorithmen von grundlegender Bedeutung ist. 
Deshalb kann es für ein gutes Iaufzeitverhalten von Program- 
systemen durchaus gerechtfertigt sein, einen "problemorientier- 
ten: virtuellen Speicher" zu organisieren, indem die Steuerung 
der Speicherhierarchie aus der Ebene des Betriebssystens in die 
Ebene elementarer problemorientierter Verarbeitungsprogranne 
gehoben wird, auch wenn dadurch ein gewisser Entwicklungsmehr- 
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aufwand: entsteht. Die dazu erforderliche Analyse der zu behan- 
delnden Problem- und Datenstrukturen mit dem Ziel der Transfer- 
minimierung kann völlig neue, effektivere Lösungsvarianten her- 
vorbringen, die sich besonders durch niedrigere Iaufzeiten 
infolge eines guten Lokalitätsverhaltens auszeichnen, 
Schließlich kommt es noch darauf an, den Nutzer des Program- 
systems nicht mit zu vielen Details der Datenverwaltung zu be- 
lasten. Dann ist es ihm auch gleichgültig, auf welcher Ebene der 
Programmhierarchie die Verwaltung der Speicherhierarchie statt- 
findet, da das Programmsystem insgesamt als "Black-Box" be- 
trachtet wird /6/. Dazu trägt die ausschließliche Nutzung der 
expliziten Datenverwaltungsfunktionen auf der Ebene elementarer 
Verarbeitungsmoduln bei. 2 


3. Parallelität in der Datenverwaltung 
Bei der numerischen Verarbeitung sehr großer Datenmengen .inner- 
halb einer Speicherhierarchie ist der erforderliche Zeitaufwand 
für Rechnung’ (CPU-Arbeit) und Transfer (I/O-Arbeit) nahezu von 
gleicher Größenordnung. Für eine effektive Datenverwaltung ist 
der Direktzugriff zu extern gespeicherten Daten eine Notwendig- 
keit. Um die dabei auftretenden Wartezeiten der ZVE zu ver- 
ringern, wurde das von der sequentiellen Dateiverarbeitung be- 
‘kannte Prinzip der Pufferung für den Direktzugriff verallge- 
meinert. Das ist gerechtfertigt, weil zwar die Zugriffsreihen- 
folge nicht mit der Reihenfolge der physischen Darstellung auf 
dem Speichermedium übereinstimmt, aber im Problenprogramn be- 
reits einige Verarbeitungsschritte im voraus bekannt ist. 
Betrachtet man den Lösungsprozeß näherungsweise als eine Folge 
von Operationen OP, (E,,A,) über einer Menge E, von Eingangs- 
daten und einer Menge A, von Ausgangsdaten (k = 1,2,...,M), 80 
ist prinzipiell folgende Vorgehensweise möglich, wobei parallel 
auszuführende Aktionen durch // getrennt sind (vgl. /2/): 

input (E,); OP, (E,,A,) // input (E,) 

for k := 2 to M-1 do 

OP, (Eysdy) // {output (A, 1); input (Eu)} ; 
OP EygrAy) // output (Ay) ; output (Ay); 
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Zur Realisierung dieser Parallelität wurde. auf der Basis eines 
Zwei-Prozeß-Systens eine elementare Seitenverwaltung geschaffen, 
die mit nur wenigen einfachen Operationen dem Problemprogrammie- 
rer die Möglichkeit bietet, effektive problemorientierte Daten- 
'verwaltungen zu konstruieren /6/. Dabei wird der Speicherraum in 
"Seiten" einer problemabhängig wählbaren Länge unterteilt. Zur 
unmittelbaren Verarbeitung des Selteninhalts muß sich dieser in 
einem "Seitenrahmen" im Hauptspeicher befinden. Die Anzahl 
dieser Seitenrahmen richtet sich nach dem aktuellen Bedarf und 
der verfügbaren Hauptspeicherkapazität. 

Zur Verwaltung der Speicherhierarchie stehen im wesentlichen die 
folgenden Operationen zur Verfügung, wobei mit S ein Identifi- 
kator des logischen Speichermediuns (z.B. Dateinummer, DD-Name), 
mit N eine Seitennummer und mit Z ein Zeiger auf einen Seiten- 
rahmen bezeichnet wird: P 


- DASSEN (Z) : Zuweisen eines freien Seitenrahmens; 

- DRELSE (2) : Freigabe eines Seitenrahmens; 

- DWRITE .(S,N,2) : Übertragung‘ des Inhalts des. durch Z angegebe- 

"nen Seitenrahnens in ale N-te Seite des Spei- 
chers 5, ohne das Ende der transferoperaklon 
abzuwarten; 

DPOINT (S,N) : Übertragung der N-ten Seite des Speichers Ss 

. in einen freien Seitenrahmen, ohne das Ende 
der Transferoperation abzuwarten; 

DREAD (S,N,Z) x Zuweisen des Seitenrahmens, der die N-te 
Seite des Speichers S enthält, wobei ggf.: 
das Ende einer Transferoperation abzuwarten 
ılst, 


„Die beiden parallelen Prozesse (CPU und I/O) wurden als Haupt- 
‚und Unteraufgabe im Betriebssystem 0S/ES simuliert. Eine voll- 
kommene Parallelität ist so nicht erreichbar, da der I/O-Prozeß 
zum Starten der Transferoperationen jeweils ein geringes 
Quantun CPU-Zeit benötigt (in Konkurrenz zum CPU-Prozeß). 

Die genannten Seitenverwaltungsoperationen können als FORTRAN- 
‚Interprogramme aufgerufen werden, wurden jedoch aus Effektivi- . 
tätsgründen selbst in der Assemblersprache realisiert. Für die 
durch FORTRAN nicht unterstützte Arbeit mit Zeigern wird eine 
einfache Simulation durch "Pseudo-Arrays" benutzt. 


+ 
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4, Anwendung 


Dieses Seitenverwaltungssystem entstand im Rahmen der Behandlung 
großdimensionierter Matrixeigenwertprobleme, wo es seine erste 
Anwendung fand. Entsprechend dem Konzept der abstrakten Daten- 
typen wurden für den Typ "schwachbesetzte symmetrische Matrix" 
elementare Matrixoperationen definiert, die für jede konkrete 
Speicherform der Matrix durch einen entsprechenden "Grundmodul" 
realisiert werden. Für den eigentlichen Lösungsalgorithmus 
(z.B. Eigenwertberechnung) bleibt damit die konkrete Speicher- 
form ebenso wie die Organisation der Speicherhierarchie verbor- 
gen, er arbeitet nur über den abstrakten Objekten unter Verwen- 
‘dung der definierten Operationen /6/. 

Die einzelnen Speicherformen für Matrizen unterscheiden sich 

in der Art und Weise der Bildung von Teilstrukturen und deren 
Abbildung auf die Seiten der Speicherhierarchie, wobei, es im- 
Interesse einer geringen Seltenwechselrate zweckmäßig ist, je 
eine logische Teilstruktur der Daten einer Seite vollständig 
zuzuordnen, auch wenn einzelne Selten dabei nicht völlig genutzt 
werden. /1/. Die Wahl der Speicherform richtet sich vor allen 
nach dem Besetzungsmuster der Matrizen (z.B. Bandstruktur, 
Zeilen- oder Spaltenprofil) und dient dem Ziel, Speicherplatz 
und ünriötige Rechenoperationen einzusparen /5. 

‚Zur Minimierung der, Transferzahl trägt auch wesentlich die 
-Simultanisierung von Iterationsverfahren bei, d. h. eine Matrix 
wird: stets auf mehrere Vektoren gleichzeitig und nicht nachein- 
ander angewendet /4/. 

Der Nachweis der durch Parallelität von Datenverarbeitung' und 
-transfer erzielten Laufzeiteinsparung ist auf indirekten Wege 
möglich, indem die Meßwerte tun t7/09 t,) für CPU-Zeit, 


Transferzeit und Gesamtlaufzeit ausgewertet werden. 

wird nit t, die Zeitdauer echter Überlagerung von GPU- und I/0- 
Arbeit bezeichnet, so gilt offenbar (unter den Bedingungen des 
Multiprogrammbetriebs): 


t7, = topu + t2/0 - to f) d. h. 


to 2 topu + tyo”-tı * 
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Die aus den Meßwerten berechenbare Größe t, stellt somit eine 
unvere Schranke für den tatsächlichen Zeitgewinn dar. 

Dieser Zeitgewinn kommt nicht nur dem betreffenden Programm 
selbst zugute, sondern gewährleistet eine insgesant bessere 
Auslastung der wertvollen CPU-Zeit durch "Erschließung unge- 
nutzter Reserven", 

In /6/ wurden bereits Meßwerte für einige Grundmoduln angegeben, 
die später auch für zahlreiche weitere Anwendungsfälle bestätigt 
werden konnten. So ergibt sich für die Grundnoduln wie auch für 
ganze Eigenwertalgorithmen eine Einsparung t) in einer Größen- 
ordnung von etwa 30 bis 90 % der benötigten CPU-Zeit, wobei man 
davon ausgehen kann, daß die CPU-Zeit für einen gegebenen Modul 
und. ein konkretes Beispiel charakteristisch ist, während die 
Transferzeiten durch zufällige Einflüsse des Multiprogrannbe- 
triebes größeren Sehwankungen unterliegen. 
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Fellin, Arne 


Zur Konzeption des Informationssystems der Deutschen Stasts- 
bibliothek 


1. Einleitung 

Ebenso, wie in anderen Bereichen der Volkswirtschaft, besteht für 
das Bibliothekswesen der DDR die Notwendigkeit, eine Vielzahl von 
Arbeitsprozessen zu automatisieren. Diese geschieht vorrangig nit 
dem Ziel, die Versorgung mit wissenschäftlichen Informationen 
qualitativ zu verbessern und den Zeitraum bis zu ihrer Verfügbar- 
keit zu verkürzen. Während in der Information/Dokumentation be- 
reits eine Reihe von Informationssystemen praxiswirksan geworden 
sind, nutzt das Bibliothekswesen nur vereinzelt Projekte, deren 
Effektivität durch ihre isolierte Stellung stark. eingeschränkt 
ist. Die komplexe Automatisierung bibliothekarischer Prozesse 
verlangt jedoch noch die Lösung einiger Probleme, die im Folgen- 
den kurz skizziert werden. 
2. Inhaltliche Problene f 

Die logische Architektur von Informationssystemen des Bibliotheks" 
wesens ist dadurch bestimmt, .daß eine Vielzahl verschiedenartiger 
Daten von Informationsquellen (im Sinne der Datenverarbeitung) zu 
verwalten und zur Nutzung bereitzustellen sind. Im Gegensatz zu 
Inf./Dok.-Systemen, die sich meist auf eingeschränkte Klassen von 
Dokumenten konzentrieren, müssen Bibliothekssystene unter anderer 
die Daten von Büchern, Zeitschriften, Zeitungen, Amtsdruckschrif- 
ten, Kartenwerken, Musikalien, Microfilmen, Platten, Tonbändern, 
Bildern usw. erfassen, warten und verftgbar machen. Für die Zwecke 
der Sachkatalogisierung lassen sich die Klassifikations-, Deskrip- 
tor- und Tresaurussystens, wie sie aus der Inf./Dok. bekannt 

sind, nützlich anwenden. Den bibliothekarisch wichtigsten Proze£ 
der alphabetischen Kataelogisierung unterstützen sie aber nur un- 
genligend. Allein für Monographien und fortlaufende Sammelwerke 
sind dabei B0OD Paragraphen der international verbindlicken Regeln 
für die alphabetische Katalogisierung einzuhalten. Zum großen 
Teil existieren auch für die anderen, oben genannten, Informa- 
tionsquellen entsprechende international abgestimmte Vorschriften, 
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Auch die inhaltliche Erschließung 'von Bibliotheksgut bereitet 
noch große Probleme, da die Informationen praktisch alle Gebiete 
menschlichen Wissens überdecken. Das gilt besonders für große 

und mittlere Bibliotheken. Entsprechende Thesaury müßten weiter- 
hin berücksichtigen, daß frendsprachige Literatur in einer Viel- 
zahl von Landessprachen in den Beständen-von Bibliotheken anzu- 
treffen ist. Dieses Problem ist zur Zeit weltweit nicht gelöst. 
Schließlich muB bemerkt werden, daß der Nutzerkreis von. Biblio- 
thekssystemen sehr 'heterogen ist ‘und einer starken Fluktuation 
unterworfen. Eine Schulung ist folglich so gut wie ausgeschlossen. 


3e Methodik 


Die genannten Probleme stellen nur. eine grobe Auswahl dar. Sie 
zeigen aber, daß sich die Entwicklung von einzelnen Projekten 
über lange Zeiträume erstrecken würde. Damit ist anzunehmen, daß 
'nach ihrer Fertigstellung die zugrundeagelegte rechentechnische 
und programmtechnische ‘Basis nicht mehr verfügbar ist. Deshalb 
ist eine komplexe Projektierung anzustreben, die auf allen Ebenen 
ein hohes Maß an Portabilität gewährleistet. Weiterhin muß die 
Lösung auf spezielle Anforderungen der Textverarbeitung /2, 5/ 
zugeschnitten sein. Die Projektierung sieht deshalb als Kern des 
Informationssystems ein relationales Datenbanksystem vor, das 
Anforderungen der Textverarbeitung gerecht wird. Als 'theoreti- 
sches Modell wird eine. Menge ebstrakter Datentypen /5/ benutzt. 
„Damit wird auf allen Ebenen eine klare Schnittstellendefinition 
gesichert, Zu ihrer Beschreibung wird die Systemprogrammierspra- 
che CONCURRENT PASTAL verwendet, wodurch die wesentlichen Ge- 
‚sichtspunkte der Pärallelverarbeitung abgedeckt werden können. 
Die. FPortabilität des Systems wird damit auf die von CONCURRENT 
PASCAL zurückgeführt. Einschränkungen ergeben sich aus dem Typ- 
konzept der Spractke, ‚das für die Verarbeitung von Textdaten 
schlecht geeignet ist. Deshalb wird zur Zeit an einer Erweite- 
rung der an der Hunboldt-Universität vorliegenden Version /6/ 
gearbeitet. Weitere methodische'Gesichtspunkte geben aus den 
folgenden Skizzen zur Architektur hervor. 


4. Das Komzunikationssysten 


Die Schnittstellen zwischen dem Nutzer und dem Datenverwaltungs- 
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system ist das Kommunikationssystem, Es realisiert die syntakti- 
sche Analyse, semantische Analyse und semantische Synthese für 
die Gesamtheit aller Nutzersprachen, Unter der semantischen Syn- 
these ist dabei die Transformation in das Standardinterface Lo | 
(s. Abschn. 6) zu verstehen. Wegen des heterogenen Nutzerkreises'' 
von Bibliothekssystemen wird die Dialogführung so gestaltet, daß 
in Abhängigkeit von den Kenntnissen des Nutzers, dieser an die 
Lösung seines Problens herangeführt wird. Das wird während der 
syntaktischen Analyse dadurch erreicht, daß nach Beendigung einer 
Eingabe entschieden wird, ob ein 

(1) vollständiger und syntaktisch korrekter 

(2) unvollständig aber syntaktisch korrekter | 

(3) syntaktisch nicht korrekter 

Satz vorliegt. Im Fall (1) wird der Satz sofort an die Verarbei- 
tung weitergereicht. In den Fällen (2) und (3) wird’ automatisch 
eine "help"-Funktion /3/ ausgelöst, die vom Zustand der Analyse 
abhängt. Als "help"-Funktionen kommen Menli- und Formtechniken zur 
Anwendung, die den Nutzer Über mögliche und notwendige Datenele- 
mente informieren. Zu den Sprachen, die auf diese Weise behandelt 
werden, zählen außer .den Recherchesprachen auch diejenigen, die 
bei der Datenerfassung Verwendung finden. Das hat seine Ursache 
darin, daß bibliographisch/bibliothekarische Daten keine stan- 
derdisierte n-Tupeldarstellung gestatten. Wegen der Vielfalt zu 
verarbeitender Sprachen müssen zu ihrer Implementierung moderne 
Technologien zur Anwendung kommen. 


5. Sprachimplementierung 


Nutzersprachen werden automatisch durch das System LAISY 
(Language Implementation supporting System) /2/ implementiert. 
Als Eingabesprache für LAISY wird eine Sprache zur Beschreibung 
von attributierten Grammatiken verwendet, die es gestattet kon- 
textfreie Sprachen syntaktisch und semantisch zu definieren. Aus 
jeder Sprachbeschreibung wird eine Tabelle zur, Steuerung der syn- 
taktischen. Analyse und ein Interpreter für die semantische Analy- 
se urd Synthese erzeugt. Der semantische Analyseteil des Inter- 
preters kann so erzeugt werden, daß auch Informationen des Data- 
Dietionary in dis semantische Analyse einbezogen werden können. 
Zweckräßig ist z.B. für die frühzeitige Kontrolle von Zugriffs- 
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rechten, der Existenz angesprochener Relationen aber auch für 
Integritätskontrollen. Die Einbettung von LAISY in das Inforrns- 
tionssystem gestatten eine flexible Anpassung an neue Anforde- 
rungen und gewährleistet damit die Erweiterungsfähigkeit. auf der: 
Kormunikationsebene, 


6. Das Standardinterface I, 


In Ergebnis der semantischen Synthese von 0.g. Interpretern ent- 
steht eine Baumstruktur. Die Gesamtheit so erzeugter-Bäume wird 
als das Standardinterface L, bezeichnet. Er repräsentiert ein 
subset von SEQUEL /1/. Als Voraussetzung wird deshalb angenommen, 
daß auf der externen Ebene nur solche Sprachen zur Anwendung 
komner, die eine eindeutige Interpretetion in SEQUEL bzw. einer 
Untermenge davon gestatten. Die SEQUEL-Repräsentation von.L, wird. 
auf.der externen Ebene dem Datenbankadministrator (als einzigem 
Nutzer dieser Spreche) zur Verfügung gestellt. Dieser nutzt sie 
zur. Wartung der Datenbasis,, des Data-Dictionary und zur Reali- 
sierung von umfangreichen Recherchen, IL, ist demgemäß Schnitt- 
stelle zwischen (dem Komnuniketionsaystem, und dem Datenverwaltungs- 
systen. Die Elemente von L, werden im Datenverwaltungssystem so 
transformiert, daß sie durch den L oInterpreter‘ abgearbeitet wer- 
den können. Die Transformation schließt das Bestimmen von Zu- 
eriffspfaden, Zugriffsoptimierung und Integritätskontrollen ein. | 


7: Data-Dictionary 


Das Datenverwaltungssystem unterscheidet zwischen virtuellen und 
physischen Relationen /4/. Virtuelle Relationen sind auf der L, - 
Ebene angesiedelt. Sie umfassen virtuelle Basisrelationen, Links 
und Selektionen. Jederi virtuellen Relation. ist ihre Realisierung 
in Gestalt einer Menge physischer Relationen zugeordnet. Das 
Data-Dictiorary enth&lt"'deshalb neben. den üblichen Informationen 
wie Zugriffsrechte, Attribütnamen, Attributtypen, 'Zustand der Re- 
lation .ı., alle Informationen über die physische Ausprägung. Da- 
mit ist le Abbildung von virtuellen Fntities däuf physische wun- 
ketirbar eindeutig definiert. Als pliysische Relationen werden im 
Daterverwaltungssystez Wurzelrelationer, Deskrirtorrelationen, 
DA-Relstionen ung SS-Relationen //Details in 4/ unterstützt. Die- 
Se Aufteilung ist an die Rotwendigkeit angepaßt, Texte als Bäume 
zu sreichern und eine Differenzierung nach Zugri?fshäufigkeit 
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vorzunehmen, 


8. Schlußbererkurgen 


von den kosponenten des geplanten Systems konnte hier. rur eine 
Teilmenge grob umrissen werden. Tiefcrgehende Aussager sind in 
jer systembezogenen Literatur zu finden. Eine Pilotimp!rmentie- 
rung ist für Ende 1993. geplant. Etwa 19285 kann das Systen für 
Nachnutzer bereitgestellt werden, 
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Wagner, Klaus 


Zum Problem _ der Anwendung der Datenbanktechnologie 


1. Problemstellung 


Die Anwendung der Datenbanktechnologie erfolgt weltweit in 
geringerem Tempo als ursprünglich erwartet. Im Mittelpunkt 
dieser Technologie steht der Einsatz solcher universeller 
Systemunterlagen bzw. Datenbankbetriebssysteme (DBBS) wie 
ADABAS, DATACOM/DB, DBS/R, IDMS, IDS, IMS usw. (weltweit ca. 
200 Systeme). Hauptzweck des Einsatzes von DBBS ist die ge- 
meinsame Benutzung von Datenelementen, Segmenten, Sätzen oder 
Dateien durch viele (EDV-)Benutzer mit unterschiedlichen An- 
wendungsprogrammen auf der Grundlage einer einheitlichen, ge- 
meinsamen Benutzerschnittstelle: dem Datenbankschema. Jeglicher 
Zugriff erfolgt in den Termen des Datenbankschemas.. 


Die Mehrheit der Aussagen zum Pro und-Kontra der Anwendung 

der Datenbanktechnologie - in der EDV-Praxis oft mit "Daten- 
bank-Würdigkeit” umschrieben '- sind unbefriadigend. Die lang- 
jährige Abstinenz wissenschaftlicher. Betätigung auf diesen. 
Gebiet bedeutete für zahlreiche Betriebe und für die in der 
EDV engagierten Mitarbeiter mitunter kostspielige Lernprozesse. 


Im folgenden werden die verschiedenen Aspekte der Anwendung 
der Datenbanktechnologie aus der Blickrichtung der. Betriebsin- 
formatik (als der wissenschaft vom Aufbau, der Arbeitsweise 

und Gestaltung automationsunterstützter betrieblicher Informa- 
tionssysteme) dargelegt. Ziel des Beiträges ist eine kritische 
Bestandsaufnahme der gegenwärtigen Aussagen zum Problem der 
"Datenbank-Würdigkeit" und die Ableitung von Schlußfolgerungen, 
die die weitere Arbeit zur Schaffung von Grundlagen der. Be- 
triebsinformatik betreffen. 


2. Stand der. gegenwärtigen Aussagen 


Im folgenden sollen die von einigen Autoren genannten Vorteile‘ 
der Anwendung von DBBS stichpunktartig angeführt werden: 
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H: WEDEKIND (1974): 


- Zentralisation der Dateien des automationsunterstützten 
betrieblichen Informationssystems 


Realisierung eines hohen Grades an Datenunabhängigkeit 


D. S. KOREIMANN (1974): 
Rationalisierung der Datenpflege 
Integration bisher unabhängiger EDV-Anwendungen 


C. 3. DATE (1976): 


- zentrale Steuerung und Überwachung der verfügbaren opera- 

tionalen Daten (des Betriebes) 

- Vermeiden von Inkonsistenzen 
“Vielfachverwendbarkeit (sharing) 
Standardisierung 
Zentrale Sicherheitsvorkehrungen 
Gewährleistung der Datenintegrität 
Vermeiden von Zugriffskonflikten 

- Datenunabhängigkeit 


= 


. ABT -(1980): 


Senken der Redundanz 

Speicherplatzeinsparung 

Vereinfachung der Pflege der Daten 

Vermeiden von Sortierungen 

Nutzer kann im DRLSNDBEFONE ohne tiefere Kenntnisse 
recherchieren 

Zugriffsberechtigung wird automatisch überprüft 
Reorganisation wird vom DBBS übernommen 


. S. APPLETON (1980): prägte das AKRONYM "IRRIASSPA": 


- data independence 
relatability 
non-redundancy 
integrity 
accessibility 
Shareability 
security 
performance 
administration 


PUWWVPHNArHr O 


Hervorzuheben sind die Untrersuchungsergebnisse von G.K. und 
9.9. Wiorkowski /1/, die sich auf eine Umfrage auf der Basis 
von 27 Unternehmen/Anwendern der DBBS ADABAS (4x), DATACOM/DB 
(5x). IMS (8x), SYSTEM 2000 (5x) und TOTAL (5x) stützen. Im 
Ergebnis der Umfrage entstand folgende Liste der Vorteile 
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(Rangfolge ist zu beachten!): 


1. Datenunabhängigkeit 
2. Datenintegrität 
3. Online-Unterstützung 
4. Zentralisierte Kontrolle der Dateien 
5. Geringer Aufwand und hohe Flexibilität bei der Restruktu- 
rierung und Pflege der Daten 
6. Verringerung der Datenredundanz 
7. Integrierte statt unabhängige EDV-Anwendungen 
8. Schnelles Reagieren auf nichtvorhergesehene Informations- 
bedürfnisse 
9. Anwendungsprogrammierer benötigen keine Kenntnisse über 
die physische Struktur der Daten. 
10. Datensicherheit und Datenschutz (security and privacy) 


Datenunabhängigkeit, Datenintegrität und die Implementierung 
von Online-Anwendungen (Echtzeitprojekte) nehmen bei den Prak- 
tikern gegenwärtig eine Schlüsselstellung ein. Die redundanz- 
arme Speicherung - neben der Speicherung der logischen Bezie- 
hungen zwischen den Daten und dem direkten Zugriff häufig als 
die Merkmale einer Datenbank genannt /2/ - rückte auf den 6. 
Platz. 


Zur Unterstützung der Entscheidung darüber, ob bei der Automa- 
tisierung einer Datenverarbeitungsaufgabe (bzw. Aufgabenklasse) 
ein DBBS eingesetzt werden sollte oder nicht ‚ wurde eine Reihe 
von Kriterienkatalogen bzw. Kriterienübersichten entwickelt: 


VIGIER (1971), HUGENBERG und 'KAISER. (1972), PLESCH und GRIESE 
(1972), LORENZ (1974) ADAM (1976), OSSWALD (1977), ERFA PPS 
Zürich (1977), 'KOSCHE (1980). 


Kritisch ist anzumerken: 


1. Die Mehrheit der Kataloge/Übersichten wurde vorrangig unter 
dem Aspekt des Einsatzes eines speziellen DBBS oder der 
Auswahl unter verschiedenen DBBS entwickelt. 


2. Die Kataloge/Übersichten gründen sich. auf konkrete Daten- 
verwaltungsanforderungen bzw. Datenverarbeitungserforder- 
nisse und orientieren allein auf die Effizienz der EDV-Pro- 
zesse (Faktor Zeit als einziger Maßstab!).- Sie!unterstützen 


423 


demzufolge weder die Einführung neuer Organisationsformen 
der EDV noch die Erschließung neuer EDV-Anwendungsgebiete. 
Die Zugrundelegung des Faktors, Zeit ist prinzipiell rich- 
tig, muß aber auf die Leitungsprozesse und Evolution des 
gesamten automationsunterstützten betrieblichen Informa- 
tionssystems ausgedehnt werden (Notwendigkeit des Unter- 
scheidens zweier Nutzenskategorien /2/). 


3. Die Kataloge/Übersichten enthalten trotz eingeengter 
Herangehensweise an das Problem der *“Datenbank-Würdigkeit" 
keine quantitativen Aussagen (Meßlatten). 


3. Wie sollte die Lösung des Problems erfolgen? 


Aus der Blickrichtung der Schaffung von Grundlagen der Be- 
triebsinforsatik sollte des Problem der "Datenbank-Würdigkeit" 
in zweifacher Weise angegangen werden: 


1. Lösungsrichtung 


Ermittlung der Kriterien der Anwendung der Datenbanktech- 
nologie für die betrieblichen Teilsysteme (horizontal- 
funktionale und. vertikal-hierarchische Gliederung der be- 
trieblichen Aufbauorganisation). 


Lösungsweg: - Bildung von Klassen/Typen automstisierter 

Informations(teil)systeme 

- Ermittlung des Zusammenhangs von Datenbank- 
technologie und der Implementierung der 
Informations(teil)systeme . 

- Zuordnung der Informations(teil)systeme zu 
den betrieblichen Teilsystemen gem. Aufbau- 
organisation 


Folgende Entwicklungstendenzen sind zu berücksichtigen: 


- zunehmende rechnergestützte Entscheidungs- 
VELNERBALUNG im Leitungs- und Planungspro- 
ze 

- verstärkte Anwendung der EDV in Forschung, 
Entwicklung sowie zur Projektierung, Kon- 
struktion und technologischen Vorbereitung 

-‘ zunehmende Integration der EDV-Prozesse 

- Dialogisierung vorhandener Stapelverarbei- 
tungs-Anwendungen 
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Der Zusammenhang von Aufbauorganisation und Informations(teil)- 
systemen wird in Abb. 1 skizziert. (Vgl. auch die Dissertatio- 
nen von H. Döringer (Mannheim 1975) und K. Garbe (Dresden 
1976).) " 


strategische infor- 


mierende \ 


b 
Ebene Datenver- 
arbeitung 
dispositive” ’ 2 
'‘operierende 
Ebene Datenverarbei- 
tung (2) 


\ N 
w. I 
operative N vv Datenerfassung 
Ebene IS N und 
A N a 
ur 3 


Anwendungsrichtung der EDV 
Rechnungsführung und Statistik 


Konstruktiv-technologische 
“Vorbereitung (PPLK= Produk- 
tionsplanung, -lenkung und 
-kontrolle als. gegenwärtiges 
Hauptanwendungsgebiet für DBBS) 


Wissenschaftlich-technische 
Vorbereitung 


Abb. 1: Betriebliche Aufbauorganisation und Informations- 
(Teil)systene 


In Abb. 1 bedeuten: (1) Planungs- und Entscheidungssysteme 
(2) Berichts- und Kontrollsysteme 
(3) Transaktionsdatensysteme 


2. Lösungsrichtung 
Quantifizierung der für die. Anwendung der Datenbanktechno-' 
logie wichtigsten Kriterien (Meßlatten-Problen!). 
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Lösungsweg: -- Definition von Maßstäben für die wichtigsten 
= Datenbankeigenschaften 
- Überprüfung der Metrik an ausgewählten DBBS 
- Entwurf einer Metrik für Informationssysteme 
auf Grundlage eines theoretischen Modells ' 
- Gewinnung von Relationen zwischen beiden 
Metriken 


Folgende Entwicklungstendenzen sind zu berücksichtigen: 


- zunehmende Bedeutung der Datenunabhängigkeit 
ale Grundlage für die 
. Evolution des Informationssystems (Stabili- 
tät trotz Wachstum!) 
. Erschließung neuer Nutzerklassen aus den 
Fachabteilungen 
. Realisierung der dynamischen Informations--- 
‘verarbeitung /3/ 
- zunehmende Bedeutung von Flexibilität bei 
gleichzeitigem Zwang zur Standardisierung, 


4. Einige Erkenntnisse (Thesen) 


1. These: Massendatenverarbeitung 


Wenn für die Automatisierung einer Datenverarbeitungsaufgabe 
lediglich (zentraler) Stapelbetrieb möglich bzw. nur diese 
Organisationsform der EDV sinnvoll ist, dann ist es schwierig, 
die Vorteile der Anwendung der Datenbanktechnologie aufzuzei- 
gen. 


Ausnahme: Kurzfristige Produktionsplanung, -lenkung und 
-kontrolle (Stücklistenspeicherung) 


Kriterien: - Effizienz der Ausführung (insbesondere bei selek- 
tiven Auswertungen mit bis zu 5 % Aktivierungs- 
rate der Datensätze in verschiedenen Dateien 1 
(Netzstrukturen) /4/) 2) ) 

= Integration von EDV-Anwendungen 

= Datenunabhängigkeit (als Schutz existierender... 
Anwendungsprogramme vor Änderungen infolge von 
Veränderungen in den Dateien) 

- Flexibilität 

- Standardisierung (der Datenverarbeitungsprojek- 
tierung und Abarbeitung im Rechenzentrum) 


1) Für entsprechende Oberlegungen ist u.a. die Zugriffslei- 
stung in Sätzen pro Minute relevant: Datenbank: 100, Di- 
rektzugriff auf Platte: 1000, sequentieller Zugriff: 10000. 

2) Die Integration besitzt mehrere Aspekte, vgl. /5/. 
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2. These: Interaktive Verarbeitung 


Der entscheidende Grund für die Anwendung der Datenbanktech- 
nologie ist gegenwärtig die Implementierung von EDV-Anwen- 
dungen in Echtzeitbetrieb, genauer: Teilhabersysteme. Dazu 
gehören: 


- Datensammelsysteme (auf der Ebene der Datenerfassung ‘und 
-verwaltung) 

- Buchungs- und/oder Direktabfragesysteme, dispositive Sach- 
bearbeiterfunktionen in .programmkontrollierter Dialogver- 
arbeitung (auf der Ebene der operierenden Datenverarbtg.) 

- Entscheidungs-Unterstützungs-Systeme und Auskunftssysteme 
für die nutzerköntrollierte Dialogverarbeitung (auf der 
Ebene der informierenden Datenverärbeitung) 


Kriterien: - dezentraler (direkter) Zugriff auf: zentrali- 
sierte Dateien 
Effizienz der Ausführung 
Datensicherheit und Datenschutz’ 
. Datenunabhängigkeit 
Standardisierung 


3. These: Neue Aufgabenklassen 


Künftige Hauptrichtung der Anwendung der Datenbanktechnologie 
ist die rechnergestützte Entscheidungsvorbereitung in Gestalt: 
von 

1. operativen Inf.ormationssystemen (hervorgehend aus der Ver- 
schmelzung von vergangenheitsbezogenen und zukunftsbezogenen 
Systemen) zur Lösung kurzfristiger Informations- und Ent- 
scheidungsprobleme auf der dispositiven und operativen Ebene 
und i 

2. Entscheidungs-Unterstützungs-Systemen zur Lösung lang- 
fristiger, nicht-programmierbarer (schlecht- strukturierter) 
Entscheidungen auf der strategischen Ebene. 


Kriterien: - Zentralisation der Dateien/Integration der 
= EDV-Anwendungen 

- zentraler (direkter) Zugriff auf dezentrale 
Dateien (Datenbanksystem, verteilte Daten- 
bank, Datenbankverbund /5/) 

- Datenunabhängigkeit (als funktions- und ‚aufga- 
benunabhängige Speicherung /3/) 

- Flexibilität 

- nutzerkontrollierter Dialog 
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5; Weiterführung ‚der Arbeiten 

Die Datenbanktechnologie ist das gesigriete Instrumentarium 
für die flexible Automatisierüng, d.i. Automatisierurig ohne 
Starrheit zu-erzeugen..Die Ermittlung der Kriterien für die 
Anwendung der Däatenbanktechnologie muß auf der Evolution des 
automationsunterstützten betrieblichen Informationssystenms, 
der Einführung neuer Organisationsförmen der EDV und der Er- 
schließung neuer EDV-Anwendungsgebiete, basieren /5, 6/. Es 
ist notwendig, diesbezüglich theoretische Grundlagen zu 
schaffen. Hiervon ausgehend und unter Berücksichtigung der 
Verantwortung des Hochschulwesens für die Grundlagenforschung 
wird daran gearbeitet, die sufgeworfenen Probleme - insbeson- 
‘dere die in Abschn. 3 formulierten - schrittweise einer (theo- 
retischen) Lösung zuzuführen. 
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Bazewicz, Mieczyszaw, and Debony, Julian 


Software organization ,and utilization 
method in a medical information system 


1. Introduction 


In the process of designing a large computer application sys- 
tem the influence of different factors on system efficiency is 
investigated. Beside the economic criterion, a number of efficiency 
criteria, depending above all upon the destination of the systen 
being designed are used in those considerations [1]. However, in 
all investigations an: essential role is played by the degree of 
adaptation of the given system to specific requirements of its 
users. Such an adaptation depends mainly on the method of 'task 
ZOrnUlatZ OH by the users, 'accepted in the system, ag well on the 
properties of system software. 

When evaluating system software, the following söftwärs 

features are mostly /e.8. [3)/ considered: z 

=- correctnegs, understood as to be the degree of fulfilling user’s 
goals, 

- reliability, or the degree, to which systen programs fulfill 
their functions with the required precision, 

- usability, or expenditure"for teaching ayatem software use and 
service, 

- efficiency, understood as to be the amount of computer 'resources 
used for handling and executing uaer’s task. 

In-order to evaluste the possibility and easiness of modify- 
ing system functions, the following properties of system software 
are taken into consideration; 

- maintainability, or the.effort required to locate and fix an, 

error in each of the system prograns, 

- testability, endersetöod as to be the, effort to test a program 
*o insure it performs its. intended functions, 

- flexibility, understood as to be the effort required to modify 
an operational progran. 

In the evaluation of the system software design an important 
‚role is performed by the amount of expenditures necessary to itg 
elaboration. 
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In the case of evaluating system adaptation to user’e- needs 
a great änfluence is exerteäd alsö by "the construction of the 
language, in which the gystem user has to prepare his task. 

The above mentioned remarks have been utilized during the 
development of the medical investigation syatem BAMED. 


2. Characteristicoe of the medical investigation aysten BAMED 


System BAMED is destined to store and process descoriptiong 
of health status of men, the descriptions being - collected during 
the consecutive visite of patiente to physicians. 

The health status of a patient ig described in the system by 
a set of values of features obtained as a result of medical exani- 
nationg and laboratory tests. The results of these examinations 
are gathered in specially elaborated medical documents which 
permit to oompile a oomplete medical profile of a given patient. 
In the description of the patient’ge health status_different foea- 
tures &merge,; Which take logical, numerical, and alphanunericd 
values. The features are grouped into blocks. In the aystem four 
basio blocks groups can be distinguished, coverings 
- anannesie, 

- physical medical examinatione, 
- laboratory tests, 
- medical diagnosis. 

In the data bage sygten the values of features of each block 
are stored in the form of one record. Thus the desoription of the 
patient’s health atatus stored in a oompact form, can be represen- 
ted as a set of reoorde. 

‚The basic feature of the system is, the possibllity of follon- 
ing changes, occouring in the time, of the health status of a 
population and of each of the patients. The use of the system ie 
particularly suitable for perforning prophylacotic investigations 
of groups of persong working in conditions being noxious for the 
heelth, as the system permitg to study the influence of the 
environment on the health status of the investigated populations, 
The system permits, to the physicien, to obtain important epide- 
miological information, so it can contribute to eliminate a number 
of factors influencing noxiously the human health status, 

The equipment of the BAHMED aysten nith a packet of prograns 
of nathematical statistics, aesures the systen to be a: convenient 
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tool for verifying medical hypotheses, e.g. concerning the cauasa 
of changes occuring in the health status of the investigated 
populations. 


3. General description of the language for task formulation 


The BAUED systen users write their tasks in the form of a 
program in a problem oriented language, which hag been elaborated 
during the system design process. 

The task, written in this language, is a sequense of directi- 
ves, instructions and paraneters. 

A directive is referred to as a sentence and servea as an 
information control for the translator of the language. When 
utilizing the problem oriented language, the following directives 
are employed: 

- PROGRAM, 

STATISTICS, 

- RETRIEVAL, 

- UPDATING, 

PERFORMING, 

- END, 

PRINTING. 

The language parameters serve to determine the data ‘object 
of each of the segment /in the progren, three different segment 
types: statistical, retrieval. and updating can. appear/, and each 
instruction. 


The parameters are uged to determine: 
= the period/s/ of examination of the patients, 
Z = the identifier of the patient or patient’e, group, 
A- the list of features. A can appear in one of the following forns 
/ feature list; . 
1) A = ) feature list; logical condition; 
: logical condition; 
here: - the feature list is a sequence of block numbers and 
feature numbers presented in blocks, 
- the logical condition can be simple or complex. If the 
first condition is fulfilled oy the patient’s data, it 
\ causes that data-are introduced from the list into the 
patient’s group the features of which are procesged in 
the segment of program. The complex logical condition 
divides a patients group into subgroups. 
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- the appearance of a logical condition without feature 
list is utilized for obtaining the output. of patients’ 
number from the group defined by parameter Z, the data 
of which fulfill that condition. 

Parametr C ig designed for determining the features processei 
by a given segment. This parameter takes one of the forms mentio- 
ned in 1), but a logical condition, in parameter ©, can be a 
simple logical condition,only. The set of features’ given in the 
features list and in-the logical condition of each instruction 
must be a subset of the featureg present in the feature list of 
tne given subset. 

In Fig. 1 a graphic interpretation of a sinple example of a 
complex logical condition is presented, that’ condition being given 
by formula (2' 


\, 
; ‚nel! (vo, ‚ucl,1cl®)), 
where: CLC - complex logical oondition, 
LC - siuple logical condition. 


Condition (2) is equivalent to the 6 following simple logical 
conditions: 


- uam ic, 
sch) ano zo ®), 
ze, an 162), 


ie ( I ano cl), 


f2) cvi=icN 


- ft) AND v2, 
‚{N n (@ 
zul and 10. ), 


Ina complex"logicatr expression two logical operatörg can 
appear: AND, -OR, and in a simple complex expression Only relation 
operators cen appear! 
EJ - Equsl, 

NE = ot Equal, 

GT = Greater hen,, 

GE = Greater or Equal, 
Li = Less Tnän, 

LE - Less or Equal. 


gu 


Fig. 1. Interpretation of a complex logical condition“ 
of form (2). 


Exanple 1. A sigple program, including one’ retrieval segment with 
one instruction of result output. 


„P /program/ } . . 

Air /retrieval/ direc$tiveg 

D=10.07.81/20.10.81; ) 

2=2D (RKS1,PRß2), | J paraneters 
c=101(4,8-3),111 (1-2),312(23),312(48):18189 2Q 9; 

WYD3 instruction 


42191 [4,8): (11191 29 1,11182 89 1(31223 GT 199,31248 GT 229)); } para- 
HR /perforn/ Br neter 
Hx fenä/ | } direötives 

The Example 1 program presents four liste of male workers 
/nans/ of. departaments RKß1, PRß2 of plant ZD. Assuming that the 
meaning of block and feature nunbers are as follous: 
10104 - first name and surnane, 
10108 - home adress, 
10103 = sex, 
10109 EQ O0 — means that the patient is a man, 
11101 EQ 1 - means that the patient does not smoke cigarettes, 
11102 EQ 1 - neans that the patient smokes more than 20 cigaretteg 

per day, 
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31223 - sugar content in the blood, 
31248 — cholesterol content in the blood. 

The first and second lists, put out by the system include 
first names, 'surnames, and adresses of non-smoking patients, in 
whose blood a sugar level greater than 100 me% and a cholesterol 
level greater than 220 mg% were detected. The third and fourth 
list include identical data of workers who smoke more than 
20 cigarettes a day. 


4. Software of the BAUED systen 


In the design of BAMED system software an important :problen 
appeared to be the selection of its structure. That selection was 
änfluenced mainly by the following system features; 

- a great number of different block types /in the present version 
the possibility of appearing' 74 different blocks, among which 
33 different record types is admitted/, 

- the 'assumption, ‚accepted a priori, of necessity of modification 
of the system software, the modificatione being connected first 
of all with the "possibility of increasing the number of blocks 
in the description of man’s health status, collected in the 
system, as well as with adding to the system new procedures, 
e.g. new algorithns of mathematical statistios, 

- the assumnption of elaborating certain programs of the systen 
by students of our faculty. 

In order to facilitate system software elaborating, and to 
facilitate system running, the following system structure, pre- 
sented in Fig. 2, has been accepted; 


Subsystem of 
=, data processi 


Subsystem of Ener 


: Subsystem of Translator 
input data data base of problem=-oriented 
checking language 


management 


program packet 
of mathematical 
statistics 


user 
program 
packet 


Fig. % General structure of the BAMED Systen. 
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The division of the system into subsystems, and the use of 
a modular structure of the software, permitted to obtain a detailed 
design of all the program modules of the systen, as well as of 
their interrelations. So the process of elaboration of all program 
modules was facilitseted, and their number could be reduced. 

In order to improve the system efficiency, the software of 
selected modules was elaborated in assembler language, among 
which most of the modules of the subsysten of date input and 
checking and the data base management subsysten, as well as the 
language  tranglator. The elaborated software of the BAMED Systen 
is very efficient, and it has all the features characterized in 
the firet part of the present paper /introduction/. However, the 
fact that some of the program modules are elaborated in assembler 
tanguage makeg it impossible to utilize direotly the aystem on 
another type of computer. 


5. Conclusiong 


The designed and elaborated method of task formulation in 
the BAMED System fulfills all the necessary conditions of a 
language of an open aystens This ig of great praotical importance, 
as the implementation of the system permits the creating of large 
files of informnstion concerning the patients health over a epan 
of years. The data can also be employed both for building mathe- 
matical models for solving selected medioal problems and for 
determining :the aymptoms of particular digseases. This is neceg= 
sary for elaborating methods of computerized medical diagnosig’ 
esisting. the physician. Cöntinuous supplementation of the lan- 
guage with new procedures will be necessary to achieve this goal. 

The software design in a modular form has facilitated its 
development oy a numerous designers team, and, in a great 
neagure, by students, as it was possible to concurrently code 
and test many modules. The introduction of nodifications to tne 
software is also easy. 
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Der Einsatz von automatisierten Informationsverarbeitunge- 
systemen (AIVS) für den Leitungsprozeß 


$ [2 wo. 


1. Einleit 


Unbestrittenermaßen stellt die ständige Vervollkonmnung der 
Prozesse der Leitung und Planung ein wesentliches Erfordernis 

in unserer heutigen Zeit dar. Dies wurde auf dem X. Parteitag 
‚der SED hervorgehoben und, um nur wenige Beispiele anzuführen,. 
'1äBt sich begründen mit der ständigen Zunahme des Umfanges 

und der Vielfalt der Produktion, der Vertiefung der gesell- 
schaftlichen Arbeitsteilung und der Zunahme des Produktions- 
potentials somohl in hochqualifizierten Arbeitskräften als 

euch modernen Arbeitsmitteln. 

Mit der Erhöhung des Niveaus der Leitungstätigkeit kommen Jedoch 
auch erhöhte Aufgaben zur Unterstützung dieser Arbeit auf die 
elektronische Datenverarbeitung zu. Dabei wird es in der Zu- 
kunft nicht in erster Linie mehr darum gehen, die langfristig 
beständigen Aufgaben des Leitungs- und Planungsprozesses zu be-. 
arbeiten, da diese im wesentlichen durch die bereits existie- 
renden EDV-Projekte unterstützt werden, sondern vielmehr darum, 
zeitlich begrenzte, schwer oder nicht vorhersehbare Aufgaben, 
‘die sich erst innerhalb des Problembearbeitungsprozesses erge- 
‚bei, in den Mittelpunkt der weitergehenden EDV-Anwendungen zu 
stellen. Diese nichtschematischen Aufgaben müssen in großer Zahl 
und kurzer Zeit bewältigt werden. Das verlangt eine wesentliche ‘- 
Erhöhung der Auskunftsfähigkeit und Reaktionggeschnindigkeit 
der EDV. Dabei geht es nicht darum, die Effizienz der EDV-An- 
wendung in erster Linie zu erhöhen, sondern ihre Effektivität, 
d.h, die erreichte Verbesserung der Leitungntätigkeit muß Maß- 
stab sein und nicht die günstigste rechentechnische Lösung. 
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Dieses Kriterium in den Vordergrund stellend,' ergeben sich für 

die Bearbeitung nichtschematischer Aufgaben zwei Fragestellun- 

gen: 

1. Wie wird die Kommunikation zwischen dem AIVS und dem Nutzer 
gestaltet? 

2. Wie muß ein AIVS. beschaffen sein, um dieAnforderungen, die 
sich durch die Bearbeitung nichtschematischer Aufgaben er- 
geben, erfüllen zu können? 


2. Die Gestaltung der Kommunikation zwischen dem Nutzer und 
dem automatisierten Informationgverarbeit seystem (AIVS). 


Eine notwendige Voraussetzung für die Effektivität der EDV für 
die Prozesse der Leitung und Planung bildet eine möglichst 
vollständige Integration der automatisierten Informationsver- 
arbeitung in das gesamte Informationsverarbeitungssysten der 
Leitung und Plenung. Aus diesem Grund komnt der Gestaltung der 
Schnittstelle zwischen dem Hutzer, wobei damit auch im weiteren 
der Informationsendverbraucher gemeint ist, und dem AIVS eine 
besondere Bedeutung zu. Wir halten es deshalb für erforderlich, 
sowohl die möglichen Hensch-Maschine-Kormunikationsformen als 
auch die vorherrschenden Aufgaben der Leitung und Planung näher 
zu charakterisieren. 


Im allgemeinen unterscheidet man die direkte und indirekte 
Mensch-Naschine-Kommunikation. 

Kennzeichnend für die direkte Mensch-Naschine-Komunikation ist, 
daß der Nutzer seine Anforderungen an das jeweilige AIVS selb- 
ständig in einer enteprechenden formalen Sprache formuliert, 

Im Gegensatz dazu kommuniziert der Hutzer bei der indirekten 
Mensch-Maschine-Kommunikation mit einer Gruppe von EDV-Speziali- 
sten, von uns als Informationszentrale (IZ) bezeichnet, der er 
seine Anforderungen in der natürlichen Sprache übermittelt, 

Die Informationszentrale setzt diese A,forderungen in eine for- 
male, maschinenverständliche Sprache um, leitet sie dem Rechner 
zu und übergibt dann die Ergebnisse in der gewünschten Form dem 
Nutzer. 
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Die. direkte Kommunikation verlangt somit zusätzliche Kenntnisse 
von Nutzer für den Umgang mit dem AIVS. Neben dem Hauptproblem 
des Nutzers, welche Daten- sind wo und wie gespeichert und welche 
Mittel ihrer Auswertung stehen ihm zur Verfügung, können sich 
weitere Fragestellungen für ihn entwickeln. 2.B.: Wie ist der 
Zugang zur EDVA im jeweiligen Rechenzentrum organisiert? Welche 
Komponenten des Anlagenbetriebssystems werden zur Abarbeitung 
des Auftrages benötigt? Wie dlgemein bekannt, sind heutzutage 
niveauvolle Softwaresysteme in der Lage, den Nutzer dabei we- 
sentlich zu unterstützen. Diee trifft aber in den meisten Fällen 
nur für die Bearbeitung von schematischen Aufgaben zu. (Eine 
schematische Aufgabe ist die Konzipierung eines gleichbleibenden 
Schemas, nach den die Abarbeitung der formulierten Aufgabe em 
folg.. Es sind Aufgaben, die sich häufig und regelmäßig wieder- 
holen und immer in der gleichen Weise ablaufen.) Auf Grund des 
begrenzten Dat 'nvolumens und der mit großer Häufigkeit wieder- 
kehrenden relat: v fest konzipierten Aufgabenstellungen lassen 
sich die zur F :herrschung notwendigen EDV-Kenntnisse minimieren. 
Je verschiedenartiger und unvorhersehbarer die Aufgabenstellun- 
gen und je komplexer die Datenbasis wird, wie. wir es überwiegend 
bei nichtschematischen Aufgaben antreffen, je umfangreicher nls- 
sen jedoch die zu. erlernenden Systemkenntnisse sein. In den mei- 
sten dieser Fälle erweist sich eine derartige Qualifizierung 

des Nutzers dann jedoch nicht mehr als sinnvoll. Bei dieser Art 
nichtschematischer Aufgaben empfiehlt .es sich deshalb, die in- 
direkte Mensch-Maschine-Kommunikation zu Penutzen: 


Wenn wir die Prozesse der Leitung und Planung unter dem Aspekt 
ihrer möglichen Automatisierung betrachten, so gehen wir von 
der Richtigkeit der folgenden zwei Thesen aus: 2 

% Auf Grund der Vielschichtigkeit, Komplexität und des überaus 
hohen Anteils an subjektiver Einflußnahme kann es keine durch- 
gängige Automatisierung der Leitungstätigkeit geben. 

2. Auf Grund der unterschiedlichen Charakteristik der Aufgaben 
der einzelnen Leitungsebenen und ihrer Einflußnahme auf den 
zu leitenden Leistungsprozeß muß das unterstützende EDV- 
System je nach Leitungsebene sich in geeigneter Weise dar- 
stellen, 
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Unter dem Aspekt von durchzuführenden Informationsverarbei- 
tungsprozessen lassen sich für Probleme drei Grundklassen en- 
geben: 

1. rein semantische Probleme 

2 eyntektisch semantisch gemischte Probleme 

3. rein syntaktische Probleme /\/ 


Unter rein semantischen Problemen verstehen wir solche, "bei de- 
nen die Informationen als Deskriptionen vorliegen und die Metho- 
den der Informationsverarbeitung nicht formalisierbar sind, d.h. 
der Problembearbeitungs- und Lösungprozeß sind bestimmend ge- 
tragen von den subjektiven Ansichten des Bearbeiters. Eine mög- 
liche Porm der Mensch-Maschine-Kommunikation läßt sich somit 
nicht zuordnen. 

Rein syntektische Probleme zeichnen sich aus durch das Vorhan- 
densein von Daten und formalisierten Verfahren (Algorithmen) zu 
ihrer Verarbeitung. Die Aufgabenabarbeitung, wie sie auch genannt 
wird, unterliegt somit keinen subjektiven Einflüssen des Bear- 
beiters. Pür eine Zuordnung von Kommunikationsformen muß man je- 
doch riter unterteilen in die Bearbeitung von schematischen und 
nichtschematischen Aufgaben. Schematische Aufgaben sollten, wie 
bereits ernähnt wurde, in einer direkten und nichtschematische 
in der Mehrzahl in einer indirekten Kommunikationsform abgear- 
beitet werden. Bei der Mehrzahl der Probleme, die bei den Infor- 
mationsverarbeitungsprozessen der Leitung und Planung anfallen, 
tritt jedoch eine Mischung von syntaktischen und semantischen 
Problemen auf. Diese syntaktigch-semantisch: gemischten Probleme 
werden von P. Keen und M. Morten in dem Buch "Decision Support 
‚Systems: an organisational perspectiye" (Addision Wesley 
publishing Company 1979) auch als halbstrukturierte Aufgaben 
bezeichnet. Sie sind gekennzeichnet durch die durch den Menschen 
zu ‘treffenden Entscheidungen, Wobei im Gegensatz zu den rein 
semantischen Problemen hier der Mensch den Rechner zielgerichtet 
zur Bewältigung von Teilaufgaben einsetzt. Der automatisierbare 
Teil dieser Problemklasse stellt auf Grund seines Charakters fast 
ausschließlich nichtschematische Aufgaben dar, so daß hier die 
indirekte Mensch-Maschine-Kommunikation Anwendung finden muß. 
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Betrachtet man nun die Informationsverarbeitungsprozesse der 
einzelnen Leitungsebenen einer Leitungshierarchie, so kann grob 
verallgemeinernd festgestellt werden, daß der Anteil rein 8YN- 
taktischer Probleme abnimmt und der Anteil rein semantischer 
Probleme mit steigender Leitungsebene wächst. Diese Tendenz 
läßt sich dokumentieren, wenn man den Charakter der ablaufenden 
Informationsverarbeitungsprozesse der einzelnen Leitungsebenen 
berlicksichtigt. Diesem Ziel dient die Abbildung 1. Wobei mit 
dieser Tabelle kein Anspruch auf Vollständigkeit erhoben wird 
und man von Verabsolutierungen Abstand nehmen sollte. 


Bentimmung des In- 
formationsbedarfe 


Erfassungsbere)j :h 
der Informati"nen 


Detailliertheits- 
grad ) 


Aktualität 


relativ schwer zu 
ermitteln 


gesamtbetriebliche 
Inform. und Inform. 
zu äußeren Bedin- 
gungen 


aggregiert 
für die Mehrzahl der 


Prozesse keine hohen 
' Ansprliche 


Frequenz der Nutzung gering 


gleichartiger Auf- 
geben 


„obere Leitungsebene untere Leitüngsebene. 


da begrenzte Problem- 
stellung relativ gut 
bestimmbar 


begrenzt auf relativ 
kleinen Bereich 


detailliert 


von großer Bedeutung, 
da vorrangig opera- 
tive Tätigkeit 


häufig 


Die syntaktisch-semantisch gemischten Probleme halten wir in den 
einzelnen Leitungsebenen' zwar vom Inhalt her verschieden, vom 
Umfang jedoch in etwa gleich, Damit läßt sich als Orientierung 
aus dem bisherigen schlußfolgern: 
1. Auf Grund des Charakters der vorliegenden Aufgaben in der? 
oberen Leitungsebene sollte die Schnittstelle zwischen dem 
Nutzer und dem AIVS als indirekte Mensch-Maschine-Kohmuni- 
kKation gestaltet werden. 
2. Für untere Leitungsebenen sollte in Abhängigkeit von der tat- 
sächlich vorrangig auftretenden Aufgabenklasse sowohl die di- 
rekte als auch die indirekte Kommunikation vorgesehen werden, 
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3. Mögliche AIVS zur Bearbeitung von nichtschematischen Aufgaben 


Im weiteren Vortrag möchten wir uns nur noch mit dem Teil an 
Informationsverarbeltungsprozessen beschäftigen, der durch nicht- 
schematische Aufgaben charakterisiert ist. Eine wesentliche Vor- 
aussetzung für die Bearbeitung dieser Art von Aufgaben stellen 
der kurzfristige Zugang zu den gespeicherten Daten und ihre 
schnelle Auswertung dar. Somit stehen die möglichen Formen und 
die Verwaltung der Datenbasis sonie die Möglicheiten ihrer Aus- 
wertung im Mittelpunkt. Bei den Formen von Datenbasen möchten 
wir uns jedoch auf die einheitlicher Datenbasen beschränken, da 
nur sie die Grundlage bilden können für eine erfolgreiche Be-- 
wältigung der meist komplexen nichtschematischen Aufgaben. 
Unter einereinheltlichen Datenbasis verstehen wir die daten- 
technische "Zusammenfassung von verschiedenen Datenbeständen 
(Dateien) eines abgeschlossenen Organisationsbereiches" /2/, 
wobei gleiche Merkmale gleich aufgebaut und die Schlüssel ein- 
‚heitlich sind. 


Somit lassen sich folgende zu einheitlichen Datenbasen zählen: 


1. Projektdateibasis: Das sind Datenbasen, die zum großen Teil 
aus den Stammdatelen der einzelnen EDV-Projekte. eines 
AIVS stammen, zentral, aber auch dezentral verwaltet 
werden und der Forderung nach Einheitlichkeit der 
Merkmale und der Verschlüsselung genügen. 

2. Potentielle Datenbasis: Das sind Datenbasen, die sich gründen 
auf vorhandene Dateien, die durchaus nicht einheitlich 
hinsichtlich der Verschlüsselung und der Merkmale zu 
sein brauchen, wobei jedoch entsprechende Schlüssel- 
und Merkmalkonvertierungsprogramme existieren. Mit 
diesen Programmen wird erst bei Bedarf die einheit- 

* liche Datenbasis für eine gewisse Zeit erstellt. 

3. Datenbank: EineDatenbank ist "in ihrem Wesen nach ein Systen, 
das aus redundanzfrei gespeicherten Daten einschließ- 
lich der gespeicherten Darstellung der Beziehungen und 
Abhängigkeiten zwischen den Daten besteht und den di- 

rekten Zugriff zu den Daten ermöglicht." /3/ 
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Die Verwaltung von Datenbasen stellt im wesentlichen ein orga- 
nisatorisches Problem der. Daß es heute dafür bereits weitgehen- 
de Möglichkeiten der Softwareunterstützung gibt, zeigen die 
Serviceleistungen der existierenden Datenbankbetriebssystene. 

Da sie im allgemeinen bekannt eind, möchten wir in unserem Vor- 
trag auf Erläuterungen verzichten. Neben dieser Art halten wir 
in bestimmten Anwendungsfällen, auf die später noch eingegangen 
werden soll, die Möglichkeit der Verwaltung der Datenbasis 

durch ein System von organisatorischen Regelungen für möglich. 
Darunter sind die folgenden, durch die schon erwähnte Informa- 
tionszentrale zu führenden Arbeitsmittel zu verstehen: 
- Datenkatalog 

- Programmkatalos 

- Listenkatalog 

- Verzeichnis ler Dateibeschreibungen 

- Verzeichnis ler Nutzungsbeschreibungen 

- Schlüsselke .alog 

- Dateiverzeichnis 
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»Für die Auswertung der Datenbasis gibt es verständlicherweise 
die vielfältigeten Möglichkeiten wie: 

- Dialogsprachen 

- Listengeneratoren 

- Programmgeneratoren 

- Progremmiereysteme u.ä, 


Bei. Datenbanksystemen macht dieser Teil der Auswertung das oder 
die externen Schemata aus. Ein oder mehrere systemeigene oder 
selbständige. Programmiersprachen werden zur Auswertung der Daten 
benutzt, 


Eine andere Möglichkeit sind Datenauswertungssystene. 

Unter einem Datenauswertungssystem (DAS) verstehen wir ein Sy- 
sten von Softwareprodukten mit möglichst hohem Automatisierungs- 
grad, das zur Lösung nichtschematiecher Aufgaben durch Auswer- 
tung von ein oder mehreren Dateien aus Projektdateibasen oder 
aus potentiellen Datenbasen eingesetzt wird. Die Art der einge- 
setzten Softwareerzeugnisse in einem DAS ist abhängig von: 
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- dem konkreten Aufbau der Datenbasis 

- der jeweiligen Aufgabencharakterietik und dem vorhandenen 
Nutzerprofil 

- der Hardware und dem Betriebssystem 

Für die Aufgaben aus dem Prozeß der Leitung und Planung werden 

dies im wesentlichen Listen- und Programmgeneratoren sein. 


Aus dem bisher Dargestellten lassen sich zwei Systeme zur Bear- 

beitung von nichtschematischen Aufgaben erkennen: 

1° Datenbanksysteme: Wobei wir darunter eine Datenbank, ein Da- 
tenbankbetriebssysten, ein Exekutivsystenm zur Auswertung 
der Daten und einen Datenbankadmiristrator zur Organisation 
“und Überwachung der Funktionen verstehen. / 

2. Detenauswertungs- und Verwaltungssysteme (DAVS): Ein DAVS 
umfaßt eine einheitliche Datenbasis,für die vorgefertigte 
Programme und organisatorische Regelungen zu ihrer Verwal- 
tung existieren, ein Datenauswertungssystem zu ihrer Aus- 
wertung und eine \Infornationszentrale, 


4. Einsatzbedingungen für DBS und DAVS 


[2 
Es ist nicht das Ziel dieses Abschnittes, DBS und DAVS in ihrer 
Leistungefähigkeit gegenüberzustellen oder eine Wertung vorzu- 
nehmen. Wir wollen vielmehr versuchen, allgemeine Bedingungen 
für‘ den Einsatz von DBS und DAVS zu formulieren. 
Gegenüber der herkömmlichen Projektierung und Programmierung 
werden für DBS im wesentlichen die folgenden Vorteile gesehen: 


- Die Datenbank bietet größere Möglichkeiten der Verarbeitung 
und Verdichtung der Daten, d.h. durch die funktions- und auf- 
gabenunabhängige Speicherung der Daten ist eine größere Zahl | 
von Pragestellungen mit vertretbarem Aufwand möglich. 

- Die Datenbank gewährleistet eine größere Aktualität des Ge- 
samtdatenbestandes. 

- Bei einer Datenbank sind weniger Kommunikationsprozegse not- 
wendig, um Daten aufzufinden. Es wird der direkte Zugriff des 
Nutzere zum gesamten Datenbestand ermöglicht. 


” 


Unterstellen wir diese Vorteile eines DBS, wobei in der Litcera- 
tur weitere angeführt werden, so müssen jedoch auch einige 
Schwierigkeiten beim Aufbau von DBS erwähnt werden, 


444 


- Nicht alle DBS genügen in gleicher Weise für jeden Anwendungs- 
fall diesen Vorteilen.‘ Deshalb ist eine auf den konkreten An- 
wender 'zugeschnittene Auswahl eines geeignetenDBS notwendig, 
auf Grund der in der DDR begrenzten Anzahl jedoch recht schwie- 
rig. 

- In der Mehrzahl der Fälle sind die Einrichtungen, bei denen ein 
DBS eingeführt werden soll, keine Neulinge auf dem Gebiet der 
Anwendung der EDV. Es’ist hier deshalb notwendig, wenn nicht 
eoger teilweise in den Anwenderbereichen, so auf jeden Fall im 
Rechenzentrum oder in der entsprechenden Einrichtung,\die be= 
stehende Orgerisation der Datenerfassung ‚-prüfung, -einspeiche- 
rung und -auswertung zu ändern. Eine solche Umstellung ist er- 
fah-ıngegemäß mit einer Reihe von Problemen verbunden. 

- Tatenbankbetriebsesysteme sind in der Regel umfangreiche Pro- 
graumsystexze. Da diese verständlicherweise nicht völlig fehler- 
frei arbeiten, treten auch aus programmtechnischer Sicht An- 
fangsschwier'gkeiten auf, 

- Durch den Uufang der Datenbankbetriebssysteme und die anzuneh- 
mende Häufigkeit der Nutzung der Datenbank werden erhöhte An- 
forderungen an die jeweils genutzte Hardware gestellt. Forde- 
rungen zum einen nach einer umfangreichen Peripherie, insbe- 
sondere an Direktzugriffedatenträger, und zum anderen nach 
einem über längere Zeit stabilen Lauf der Rechenanlage. 


Die aufgezeigten Schwierigkeiten machen deutlich, daß es nicht 
in jedem Fell sinnvoll ist, DBS einzusetzen. Die nachfolgenden 
Punkte sollen dem Anwender eine Unterstützung bei der Entschei- 
dung sein, 


1. Haben‘die Daten tatsächlich einen solchen Umfang erreicht, 
daß sie nurnoch durch ein DBS verwaltet erden können? 

Ist die Verflechtung der Daten eo stark, "daß ihre Struktur: 
nur noch in einer Datenbank widergesplegelt werden kann? 

3. Eine Senkung der Redundenz imDatenbestand, insbesondere bei 
der Pri mürdatenerfassung, läßt sich durch gute organisatori- 
sche Maßnahmen etenfalle ermöglichen, wobei die Redundanz- 
armut eines DBS jedoch richt erreicht wird. 


A4S 


4. DBS sind gekennzeichnet durch eine hohe Aktualität des ge- 
samten Datenbestandes. Ist diese Aktualität für alle Daten 
vennöten, oder ließe sie eich auch für die geforderten Daten 
durch gesonderte Programme erreichen? 

5. Die Möglichkeiten der ONLINE-Verarbeitung eind in großen Stil 
wohl nur durch DES realisierber. Zu fragen iat, cb diese Art 
der Verarbeitung für den Informationsendverbraucher tatsäch- 
lich von Nutzen ist. 

Auch wenn die letztgenannten Punkte den Anschein geben, kann 

es nicht Anliegen sein, gegen die Einführung von DBS zu ergu- 

mentieren. 


Ziel unseres Beitrages war ee, eine Einordnung von möglichen 
AIVS zur Bearbeitung von nichtschematischen Aufgaben aus den 
Leitungsproze£ vorzunehmen und sowohl die Eignung von DAVS ale- 
such DBS für diese Art yon Aufgaben hervorzuheben. 
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Fichtner, Norbert 


Interdisziplinäre Zusammenarbeit bei Anwendung der automatisierten 


Informationsverarbeitung im Gesundheitswesen und in der Medizin 


Die Notwendigkeit der interdisziplinären Zusammenarbeit bei Anwen- 
dung. der automatisierten Informationsverarbeitung im Gesundheits- 
wesen und in der Medizin ergibt sich aus 


- den gesundheitspolitischen und technisch-organisatorischen 
Erfordernissen bei der Überwachung und weiteren Verbesserung 
des Gesundheitszustandes der Bevölkerung 


- dem progressiven Anwachsen des internationalen Erkenntnissten- 
des *, der Medizin 


- deı wissenschaftlich-technischen Fortschritt in Einheit mit dem 
Wachstum der fFroduktivkräfte 


- der gesellschafclichen Forderung nach effektiverer Auslastung 
der dem Gesur ıheits- und Sozialwesen zur Verfügung gestellten 
finanziellen,‘ materiellen und personellen Fonds. 


Diese objektiv vorhandenen Bedingungen äußern sich in einer stän- 
digen Zuna'ıme von Informationen, die es zu verarbeiten 'gilt, um 
die Errungenschaften der modernen Medizin gezielt zum Wohle der 
Bürger nutzbar zu. machen sowie die Qualität und Wirksamkeit der 
medizinischen Betreuung kontinuierlich zu erhöhen, 


Partei. und Staatsführung nehmen seit Jahren auf disse Entwicklung 
gezielt Einfluß und im Ergebnis dieser Bemühungen konnte auf dem 
X. Parteitag der SED festgestellt werden, daß die Forderung nach 
engem Zusammenwirken von Grundlagenforschung, angewandter For- 
schung sowie technischer und technologischer Forschung und Ent- 
wicklung immer besser. verwirklicht wird. /1/ \ 

Weiterhin wird festgestellt: 

"Die enge Beziehung der Forschungskollektive zum wissenschaftli- 
chen Gerätebau und zur Entwicklung hochempfindlicher Technik ist; 
zu einen wichtigen. Bestandteil des Forschungsprozesses geworden, 
Dazu wird auch die Ausarbeitung und Bereitstellung .leistungsfähi- 
ger Verfahren und Systeme der Datenverarbeitung und -übertragung 
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sowie der Ausbau der wissenschaftlichen Information und Dokumen- 
tation." /1/ 


Die Anwendung der automatisierten Informationsverarbeitung im 
Gesundheitswesen und in der Medizin kann in folgende Komplexe 
grob untergliedert werden: * 


- Unterstützung der Prozesse der Leitung ünd Planung des GSW 

- automatisierte Meßwertverarbeitung 

- rechnergestützte patientenbezogene und betriebliche. Informa- 
tions- und Dokumentationssysteme 

- Unterstützung der Dispensairebetreuung 

- Unterstützung der medizinischen Forschung 

- Rationalisierung der Versorgungsprözesse. 


Die Vielfalt der informationellen Beziehungen auf diesen Gebieten 
verdeutlicht, daß die automatisierte Informationsverarbeitung 
direkt und indirekt in die gesundheitliche Betreuung der Bürger 
eingreift. Gleichermaßen geht aus’ den zahlreichen Einsatzfällen 
in den genannten Bereichen hervor, daß Fachwissenschaftler der 3 
unterschiedlichen Disziplinen eng mit dem Mediziner zusamnenar- 
beiten müssen, um die anfallenden Informationen zu beherrschen, 
zu verarbeiten und zu nutzen, Die hierbei beteiligten Wissen- 
schaftsdisziplinen lassen sich grob in drei Gruppen gliedern, 

Das einds 


1. Durchgängig Mediziner der verschiedenen Fachrichtungen 
2. Durchgängig Informationswissenschaftler und -techniker 


3. Wissenschaftler und Fachleute der unterschiedlichen Wissen- 
schaftsdisziplinen entsprechend der Spezifik der genannten 
Einsatzgebiete, 


Die interdisziplinäre Zusammenarbeit vollzieht sich zwangsläufig 
und selbstverständlich im Prozeß der Arbeit, Andererseits ist sie 
Jedoch verstärkt urld bewußt durchzusetzen und zu qualifizieren, 
um die Effektivität der Arbeit zu erhöhen, die medizinische. Be- 
treuung weiter zu verbessern und die Wirksamkeit der Forschung Zu 
erhöhen. Eben dieses Anliegen wird auch durch staatliche Maßnah- 
men unterstützt, so durch die Einführung des postgradualen Stu- 
diums für naturwissenschaftliche und technische Hochschulkader 
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sowie Dipl.-Psychologen und Dipl,-Soziologen im Gesundheitswesen 
1981. Die Weiterbildung der naturwissenschaftlichen und techni- 
schen Hochschulkader erfolgt gegenwärtig in 18 Fachrichtungen, 
u.a. auf den Gebieten Biochemie, Biomathematik, Biophysik, klini- 
sche Chemie und Labordiagnostik, klinische Strahlenphysik, Kommu- 
nalhygiene, klinische Arbeitshygiene und medizinische Soziologie, 


Ziel des postgradualen Studiums ist es, in enger Gemeinschafts- 
arbeit von naturwissenschaftlichen und technischen Hochschulka- 
dern mit Ärzten, die Medizin durch die Nutzung neuer Erkenntnisse 
der Biologie, Chemie, Mathematik, Physik, Technik, Psychologie 
und Soziologie zu bereichern, indem es die genannten Hochschul- 
kader befähigt, berufebezogene spozielle Tätigkeiten in der medi- 
zinischen Forschung und Betreuung ‘in höher Qualität auszuüben. /2/ 


Eberiso wie sich der Informationsenissenschaftler und -techniker in 
die Spezifik des medizinischen Fachgebietes einzuarbeiten hat, 
müssen auch an d .n Medizinoör,. der Verfahren: und Methoden der 
automatisierter Informationsverarbeitung nutzt, bestimmte Bil- 
dungsforderungen als Grundlage einer effektiven interdisziplinä- 
ren Zusammenarbeit gestellt werden. Das sind u.a. Kenntnisse über 
die Leistungsfähigkeiten, die Möglichkeiten und Grenzen .der Nut- 
zung eine elektronischen Datenverarbeitungsanlage mit Schwer- 
punkten wie: 


- Wer ist Anlaufpartner im Rechenzentrum für den Mediziner? 

- Welche vorhandenen Möglichkeiten können genutzt werden? 

- Abschätzung des Nutzens und Aufwandes maschineller Aufberei- 
tungen 

- Kenntnis über die Anforderungen, die an das von dem Mediziner 
übergebene Material zu stellen sind usw. 


Einige Bemerkungen zu konkreten Anwendungsgebieten. Bei der rech- 
nergestützten Bereitstellung von Informationen zur Rationalisie-- 
rung und Qualifizierung der Leitungs- und Planungsprozesse im 
Gesundheits- und Sozialwesen gehören zur Realisierung der inter- 
disziplinären Zusammenarbeit zu der o,a, 3. Gruppe der beteilig- 
ten Fachleute Gesundheitspolitiker, Staatswissenschaftler, Okono- 
men und Juristen, 

Zur matericll-technischen Absicherung der ständigen Erhöhung von 
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Qualität und Wirksamkeit der medizinischen Betreuung. der Bürger 
bei der Prophylaxe, Diagnostik, Therapie und Metaphylaxe wurden 
bis 1980 mehr als doppelt so viele Investitionen wie im vorher- 
gegangenen 5-Jahrplan dem Gesundheitswesen zur Verfügung gestellt, 
Insgesamt wurden im Zeitraum vön 1970 bis 1980 ca. 4 Milliarden 
Mark dem GSW zur Verfügung gestellt. Die Zahl der Beschäftigten 
im GSW- beträgt annähernd Y2 Million; das entspricht 5,7 % des 
gesamten gesellschaftlichen Arbeitsvermögens der DDR. Mehr als 
42 000 Ärzte und Zahnärzte sind in der DDR tätig,. jährlich sind 
etwa 2,3 Millionen Krankenhausabgänge sowie eine ständig stei- 
gende Anzahl'von Konsultationen im ambulanten Bereich organisa- 
torisch zu bewältigen. Die Anzahl der Konsultationen in staatli- 
chen ambulanten Einrichtungen einschließlich der Hausbesuche 
betrug im Jahre 1960 noch 61,7 Millionen; 1980 waren es 142,3 
Millionen. Zur Zeit sind in der ambulanten Betreuung im Wohnge- 
biet von einem Arzt (im Mittel aller Fachrichtungen). je Arbeits- 
tag etwa 50 Konsultationen und Hausbesuche zu bewältigen, 'wenn 
200 effektive Arbeitstage/Jahr angenommen werden, 

Die interdisziplinäre Zusammenarbeit bei der rechnergestützten 
Verarbeitung der sich aus den genannten Kennziffern ergebenden 
Vielzahl von Informationen muß sich aus gesundheitspolitischer 
und volkswirtschaftlicher Sicht konzentrieren auf: 


- die Ermittlung des Bedarfes der Bevölkerung an medizinischer 
und sozialer Betreuung 

- die Beurteilung der Bedarfsbefriedigung 

- die Einschätzung der Qualität der medizinischen und sozialen 
Betreuung 

- die Verbesserung der Ausnutzung der Fonds und der Auslastung 
der Kapazitäten 

- die Nutzung von Informationen aus der epideniologischen For- 
schung durch ihre Verknüpfung mit Leitungs- und Planungsin- 
formationen, 


Die interdisziplinäre Zusammenarbeit bei der rechnergestützten 
Lösung dieser Aufgabenstellungen beginnt bereits bei der Analyse 
der nutzbaren bzw, aufzubauenden Datenfonds und setZt sich bei 
der Entwicklung der konkreten EDV-Projekte entsprechend den Stu- 
fen E1 bis E6& der Nomenklatur der Arbeitsstufen und Leistungen 
von Aufgaben des Planes Wissenschaft und Technik fort. Dabei 
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wird der Umfang der von anderen Fachdisziplinen außerhalb der In- 
formationsverarbeitung zu erbringenden Leistungen mit den einzel- 
nen Projektierungsstufen geringer, 


Die automatisierte Meßwertverarbeitung dürfte das Einsatzgebiet 
der elektronischen Datenverarbeitung sein, auf dem die intordis- 
ziplinäre Zusammenarbeit am ausgeprägtesten ist. und den größten 
Unfang erreicht, Die hier beabsichtigte rechnergestützte Ent- 
scheidungsfindung für Diagnostik, Therapie und Prognose erstreckt 
sich auf die Gebiete: 


- Laborautomatisierung 
(z.B. Hämathologisches Labor, klinisch-chemisches und mikro- 
biclogisches Labor, Isotopenlabor) 

- Radiologie 

- Funktionsdiagnostik/Biosignalanalyse 

- Fatientenüberwachung in der Intensivtherapie 


- Bildverarbei.ung. 
) 


Gerade auf dio-am Anwendungsgebiet der automatisierten Meßwert- 
verarbeitung Langiert die interdisziplinäre Zusammenarbeit in 
gravierender Weise die Industrie, Sie hat entscheidenden Anteil 
an der Entwicklung und der Bereitstellung von Systemlösungen, die 
in. breitem Umfang im.GSW einsetzbar sind. Als Beispiel hierfür 
sei das Mikrorechnersysten zur Bestrahlungsplanung Robotron dopey-r 
angeführt, Auf der Grundlage des Mikrorechners Robotron K 1630 
und einer Konfiguration, die den speziellen Erfordernissen :der 
Nutzer angepaßt werden kann, wurde die notwendige Software ge- 
meinsam von Physikern und Medizinern des Zentralinstitutes für 
Krebsforschung und Mitarbeitern des Rechenzentrums des Zentral- 
institutes für Molekularbiologie der Akademie der Wissenschaften 
der DDR entwickelt. \ 


Die Bemühungen progressiver Mediziner und aufgeschlossener, 
kooperationsbereiter Naturwissenschaftler und Techniker unter- 
stützten und unterstützen, beschleunigten und beschleunigen die 
Entwicklung der Medizin zu einer analytischen und weitgehend 
quantitativ objektivierbaren Wissenschaft in dem Bewußtsein, daß 
diese in der historischen Anlage bedingte empirische Wissenschaft 
in starkem Maße von der Entwicklung der Technik und den entspre- 
chenden mathematisch-naturwissenschaftlichen Disziplinen beein- 
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flußt wird. Entsprechend der engen und wechselseitigen Verbindung 
zwischen deskriptiver ünd analytischer Methodik in der medizini- 
schen Forschung kommt dabei gerade der mathematischen Statistik 
eine spezifische Bedeutung bei der Gewinnung und Absicherung 
quantifizierbarer medizinischer Ergebnisse zu. Hierbei erscheint | 
es. als wesentlich, unsere Mitarbeiter zu motivieren, die schnelle, 
zuverlässige und umfassende Erhebung und Auswertung der medizini- 
schen Datenbestände zu unterstützen, Die Kompliziertheit der an- 
gewendeten mathematischen Modelle und Verfahren, die Notwendig- 


keit, ständig und schnell zu Zwischenergebnissen zu gelangen, 
verschiedene Möglichkeiten zu testen, korrigierte Rechnungen 
durchzuführen erfordern die verständnisvolle, umfassende, inter- 
essierte und wissenschaftlich verantwortungsbemußte problenorien- 
tierte Mitarbeit und Zusammenarbeit der Fachwissenschaftler in 
der Medizin und in den Rechenzentren. Es ist ein gesellschaftli- 
ches Erfordernis, einen aufwandsadäquaten Nutzen beim Einsatz der 
EDV im Interesse ungerer Bürger zu erbringen. 


Wenn ich eingangs gesagt habe, daß die umfassende, effektive und 
sachgerechte Anwendung mathematisch-statistischer Methoden und 
Verfahren sonie die Nutzung entsprechender mathematischer Modelle 
in der medizinischen Betreuung und Forschung den Einsatz der 
elektronischen Datenverarbeitung erfordern, leitet sich gleich- 
zeitig aus den Erfordernissen der modernen praxiswirksamen medi- 
zinischen Forschung die spezifische Aufgabenstellung der mathenma- 
tisch und informationstechnisch orientierten Disziplinen ab. Bei 
der epidemiologischen und medizinseoziologischen Forschung wird in 
allgemeinen pro Person eine. bestimmte Anzahl von Merkmalen in 
Form von statistischen Variablen erfaßt, wobei die Auswertung der 
Datensätze sequentiell erfolgt. Aus der Vielzahl und Kompliziert- 
heit der zu berücksichtigenden Merkmale und ihrer Ausprägungen 
ergeben sich beilder: Anwendung mathenatisch-statistischer Verfah- 
ren unter Nutzung der EDV häufig Schwierigkeiten, Sie zu überwin- 
den, stellt ebenso eine Aufgabe des in Anspruch genommenen Rechen- 
zentrums dar, wie die Mithilfe und methodische Beratung bei der 
Lösung von - teilweise subjektiv bedingten - Problemen. Das be- 
trifft vor allem‘ die Unterstützung bei der: 


- Herausarbeitung klarer und arböitsfähiger Zieletellungen für 
die statistische Auswertung der Daten sowie bei Unterstützung 
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einer exakten Aufgabenformulierung 

- Erarbeitung methodischer Konzeptionen. bezüglich der Dat6nerhe- 
bung und ihrer weiteren Verarbeitung 

- Erfassung eindeutiger im Sinne mathematischer Algorithmen ver- 
arbeitungsfähiger Daten / 

- Erarbeitung und methodisch übersichtliches Angebot einer aus- 
reichenden Anzahl in ihrer Anwendung und Ergebnisdarstellung 
getesteter mathematischer Modelle und Verfahren, 


Die objektive Notwendigkeit eimer engen und über die Kooperation 
hinausgehenden Zusammenarbeit zwischen Medizinern und Wissen- 
schaftlern informationstechnisch und mathematisch orientierter 
Disziplinen liegt im vergleichsweise geringen Integrationsgrad 
mathomatischer Methoden und Verfahren in der Medizin begründet. 
Die Biometrie steht als eigenständiges Fächgebiet neben den bio- 
logischen Wissenschaften, während in anderen Wissenschaftesdiszi- 
plinen wie Physik, technische Mschanik, Elektrotechnik, OUkononie 
u.a, die Integration der Mathematik in der Fachwissenschaft 
selbst vollzc ‚en ist. Dadurch erhält der in volkswirtschaftlichen 
und wissenschaftlich-technischen Bereichen tätige Informations- 
wissenschaftler die Problemstellung von der fachlichen Seite her 
soweit aufbereitet, daß die mathematische Algorithmi:serung bzw. 
die prot.lemanalytische, programmier- und rechentechnische 'Bear- 
beitung relativ problemlos erfolgen kann. Die dem Rechenzentrum 
übergebene fachspezifische Problemstellung ist in ihrer Frage- 
stellung weitgehend durchdacht und /relativ ausgereift, 


Die Befähigung des Mediziners zur Nutzung der automatisierten 
Informationsverarbeitung als wesentlicher Faktor zur integrati- 
ven Zusammenwirkung von theoretischer und klinischer Medizin in 
Verbindung mit technisch-naturwissenschaftlichen Disziplinen 
sollte durch die praxisnahe Einbeziehung des Fächgebistes auto- 
matisierte Informationsverarbeitung/mathematische Stetistik in 
die Aus- und Weiterbildung der medizinischen Kader erreicht wer- 
den, Hierbei häben wir Erfolge erzielt; aber wir haben hier noch 
erhebliche Arbeit zu leisten, gemeinsame Arbeit zu leisten, um 
auch diese Möglichkeiten der Weiterbildung bewußt auszunutzen, 
die integrative Zusammenarbeit zu stärken und damit die.For- 
schungs- und Betreuungsprozesse in der Medizin zu unterstützen, 
Dabei sollten bei der Weiterbildung der medizinischen Kader die 
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funktionellen Aspekte der Datenyerarbeitung hervorgehoben werden, 


während die technischen Aspekte weitgehend eingeschränkt werden 
sollten, 


Die Darlegungen sind als Anregung und Unterstützung gedacht, die 
Forderungen von Partei- und Staatsführung nach engem Zusammen- 
wirken aller \iissenschaften, aller Wissenschaftsdisziplinen und 

Ausprägung der sozialistischen Gemeinschaftsarbeit zur Stimulie- 
rung der wissenschaftlichen Arbeit zu erfüllen und der herausge- 
stellten Bedeutung der Entwicklung der Grundlagen- und angewand- 
ten Forschung in den Biowissenschaften einschließlich den natur- 
wissenschaftlichen Grundlagen der Medizin gerecht zu werden, 

Hierbei tragen wir als Informationstechniker und -theoretiker 
eine spezifische Verantwortung, 


Literaturhinweise 


/1/ Bericht des Zentralkomiteos der Sozialistischen Einheits- 
partei Deutschlands an den X, Parteitag der SED 
Dietz Verlag Berlin 1981 


/2/. Anweisung über das postgraduale Studium für naturwissen- 
schaftliche und technische Hochschulkader sowie Piplom- 
psychologen und Diplomsoziologen im GW vom 01.04.1981 
Verfügungen und Mitteilungen des MfGe Nr.4 vom ‚04.05.1981 


Verfasser: 

Dr.Dr.sc.nat, Norbert Fichtner 

Institut für Sozialhygiene und Organisation des 
Gesundheitsschutzes "Maxim Zetkin" 
Organisations- und Rechenzentrum 


1134 Berlin, -Nöldnerstr. 34-36 


454 


"Melzer, Jürgen 


Die Beziehung zwischen Struktur und Auswertung bei patiehten- 
bezogenen Datenbeständen 


1. Einleitung 
Die Vermeidung von Datenfriedhöfen, d.h. die Existenz von 


kaum oder schwer auswertbaren Datenbeständen innerhalb von 
Informationssystemen, stellt heute ein anerkanntes Problem 
dar. Besonders in der Medizin, wo mehrjährige retrospektive 
Auswertungen sehr oft Ausgangspunkt bzw. wesentlicher Bestand- 
teil von Forschungsprozessen sind, erweist sich die Berlicksich- 
tisung des Zusammerhangs von Gestaltung, Struktur und Auswert- 
barkeit. als besonders notwendig. 

Betrachtet man die Datenauswertung in ihrer Gesamtheit, d.h. 
einschließlich aller notwendigen Zwischenschritte und Hilfs- 
arbeiten, wı:d deutlich, daß es sich in struktureller Hinsicht 
um mehrere Ehenen handelt: 


- reale. Stıuktur der Wirklichkeit 


- logische Struktur der’ Daten 
- physische Struktur der Daten. 


! 


Die Auswertung ist damit auch ein Transformationsproblem (Über- 
gang zwischen den Ebenen), das nach Auffassung des Autors nicht” 
vollständig automatisierbar ist. D.h. im allgemeinen ist die 
Lösung eines Auswertungsproblems immer mit einem Anteil in- 
telligenter menschlicher Tätigkeit verbunden, Hierin liegt die 
wesentlichste auswertungsspezifische Aufgabe der Informations- 
zentrale (siehe auch Beitrag von Hagen, Klaembt, Schirmbacher). 


2. Begriffserläuterungen 
Die folgenden "Erläuterungen resultieren aus der Sicht und dem 


Verständnis des Autors, Es wird damit keinesfalls beabsichtigt, 
eine liber das Thema hinausgehende allgemeingültige Definition 
zu geben. 


Struktur der Daten (physische): 
- Begriff für das verwendete Prinzip der Anordnung einer nie- 
deren in einer höheren Organisationseinheit der Daten (z.B, 
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Datum im Iatensats, Datensatz in der Datei) 
- sichert die Ordnung und damit die Identifikation (Adressierun) 
als Voraussetzung einer zweckmäßigen Verfügbarkeit der Daten 
- nach ihr erfolgt die jeweils konkrete Datenorganisation. 


Gestältung der Daten: 

Unfast 

- Problematik des Umfangs, der Auswahl und der inhaltlichen Be- 
ziehung. der erfaßten (gespeicherten) Daten sowie 

- Problematik der Abbildungstreue der Daten in Bezug auf den 
abzubildenden Prozeß. 


Logische Struktur _der Daten: 
-Bildet die Grundlage zur Übersicht über ‘die Datenmenge (Orien- 


tierungsmittel) 
- ermöglicht die .Identifiketion. der Daten... 
- ist die Vomubsetsung fürn jegliche 'Nutzbarmachung von Daten- 
mengen 
- entsteht auf der Basis der Gestaltung der Daten. 
Auswertung (Datenauswertung im Sinne des Beitrags): 
Bezeichnet den diskontinulerlichen Progeß der Lösung bzw, Bear- 
beitung von vorwiegend einmaligen Informationsverarbeitungsauf- 
gaben mit Hilfe der automatisierten Informationsverarbeitung 
euf der Basis bereits vorliegender maschinell gespeicherter 
Daten. 
Dabei bedeutet 
Nyorwiegend einmalig"; Es gibt Aufgaben (z.B. jährliche Analy- 
sen), die im bestimmten zeitlichen 
Rhythmus wiederholt werden, 

"mit Hilfe der automatisierten Informationsverarbeitung": 

Die Lösung umfaßt menschliche und maschi 
nelle Tätigkeiten. 

" auf der Basis gespeicherter Daten": Die Erfassung und Aufbe- 
reitung (Prüfung) ist nicht Bestandteil 
der Datenauswertung. 

Bei vergleichenden Auswertungen - zu dieser Gruppe gehören u.a. 
die in einem bestimmten zeitlichen Rhythmus sich wiederholenden 
Auswertungsaufgaben und natürlich auch die bereits erwähnten, 
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für die medizinische Forschung besonders wichtigen, mehrjähri- 
gen retröspektiven Auswertungen - ist die Forderung nach einer 
kontinuierlichen Qualität der Auswertung hinsichtlich der Brauch- 
barkeit der Ergebnisse von entscheidender Bedeutung. Im über- 
tragenen Sinne könnte man auch von einer "Stetigkeit der Aus- 
wertung" sprechen, ; 


Zum Verständnis: 


Datenbestände 


aktuelle archivierte 


(Zeitraum 9) Pr; | 8 


Zeitraum 1 Zeitraum 2 \ ...ä 


Läuft eine Auswertung Über mehrere inhaltlich vergleichbare Ia- 
tenbestände (z.B. über mehrere Zeiträume) so muß zur Wahrung 
der Forderuns .naoh einer kontinuierlichen lität (bew. Ste- - 
tigkeit) de) Auswertung für jede Auswertungsaufgabe (AwA) gelten: 


Die Existenz einer Lösung auf der Basis einer Teiles des aus- 
zuwertenden Datenbestandes sichert eine vergleichbare Lösung 

auf der Basis jedes beliebigen Teiles des auszuwertenden Da- 

tenbestandes, 


3. Die Dynamik des Datenbestandes als Problem der Struktur 


Für komplexe rechnergestützte Informationssystene (IS) jegli- 
cher Art gilt, daß sie im allgemeinen nicht mit einem Schlag 

im vollen geplanten Umfang eingeführt werden können. Die Gründe 
hierfür sollen hier nicht näher erörtert werden, Nur soviel sei 
gesagt, daß sie sehr vielfältig und nicht nur von trivialer 

Art sind. Neben technischen und organisatorischen Problemen 
treten mit wachsendem Umfang des IS vor allem soziale’ Probleme 
auf. 

Besonders in den Betreuungseinrichtungen des’ Gesundheitswesens, 
wie z.B. in den Versorgungskrankenhäusern mit ihren historisch 
gewachsenen Organisationsstrukturen und Lei&tungshierarchien, 
ist die Akzeptansproblematik eine nicht zu unterschätzende 
Größe. Die schrittweise Einführung des IS ist hier gewöhnlich 
der einzige gangbare Weg. Die Maßnahme‘ führt natürlich damı, 


457 


daß der Umfang der vom IS erfaßten, zu verarbeitenden und zu 
speichernden Informationen bzw. Daten sich stufenweise erwei- 
tert, 

Diese Diskontinultät hinsichtlich des Umfangs und der inhalt- 
lichen Gestaltung der für ein IS relevanten Daten ist aber kel- 
nesfalls mit der vollen Einführung des IS beseitigt. IS reali- 
sieren ja immer in irgendeiner Form eine Abbildungsfunktion 

der realen Umwelt, in der sie eingebettet sind. IS sind ein Teil 
der Betriebs- bezw. Krankenhausorganisation. Oft sind sie auch 
noch in regionale Organisationen (Signierstreifen, Berichtswesen) 
eingebunden. Damit unterliegen sie mehr oder weniger 'einem 
ständigen Druck nach Anpassung d.h, Veränderung. 

Als Beispiel -seii4e für solche Kußere: Einflüsse, die-in ‘den 
letzten Jahren auf Patienteninformationssysteme unabhängig 

von ihrem Einsatzort und ihrer Entwicklung wirkten, seien ge- 
nannt: 


- Änderung :des_ standardisierten Krankenblattes (Aufbau). 

- Änderung‘ das. Sienierstreifens (Aufbau und Inhalt, Hinzünahne‘ 
bisher nicht erfaßter Informationen) N 

- Einführung der 9. Revision des WHO-Miagnose-Sohlüsselverzeich- 
"nisses (veränderte Schlüssel, Wegfall des Sicherheitsgrades). 


Innerhalb unseres Krankehäuses wurde eine Umbenennung der Sta- 
tionen vorgenommen (neben neuen Bezeichnungen wurden Beziehun- 
gen unter den Daten dadurch verändert). 

Bei Patienteninformationssystemen, die im wesentlichen Infor- 
mationen zum medizinischen Betreuungsprogzeß der einzelnen Pa- 
tienten verarbeiten, folgt insbesondere aus. der ständigen Wei- 
terentwicklung der medizinischen Wissenschaften, z.B. durch 

neue Diagnostikverfahren, hHeue therapeutische Erkenntnisse 

(u.a. auch als Folge der Auswertung von entsprechenden patien- 
tenbezogenen Daten, dh. infolge der eigenen Arbeit), neue NMe- 
dikamente ua.m., die Notwendigkeit einer ständigen Anpassung 

der vom IS zu verarbeitenden Informationen an den abzubildenden 
Prozeß. Neben diesen objektiven Gründen treten noch subjektive 
Faktoren als Ursache für Änderungen auf. Hier wären insbesondere 
die persönlichen Interessen und Beziehungen der am Prozeß be- 
teiligten oder ihn leitenden Kadern zu nennen. Die historisch | 
gewachsene Organisation und Hierarchie des medizinischen Betreuung 
prozesses begünstigt das Auftreten und Wirksamwerden dieser | 
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subjektiven Faktoren, 


Die Einordnung des IS und die jeweilige, eine Veränderung des 
Datenbestandes verursachende, Folge: 


Fakt \ Folge 
Die Komplexität des /S Die schrittweise Einführung 
- organisatorische des IS 
- soziale 
- technische 
- programnseitige 
Di. Einbettung des IS in Anpassung an veränderte Organi- 
Organisationen Organisationen 
- betriebliche 
regionale 


- landesweit 


Die Abbildur ‚sfunktion des IS Anpassung an die Veränderungen 


- Prozesse der abzubildenden Objekte bzw. 
- Objekte Prozesse 
Das IS als Realisierung von Berücksichtigung der anhaltenden 


Datenverarbeitungstechnologie Evolution auf diesem Gebiet 
- Hardware 
‚- Software 


Fazit: r 

Durch die Einbettung der IS in gesellschaftliche Organisationen 
und die Abbildung realer gesellschaftlicher Prozesse durch das 
IS unterliegt die zu verarbeitende Informationsmenge einer 
ständigen Dynamik,..d.h. die dazugehörigen Datenbestände können 
nur eine relative Stabilität besitzen, wenn das IS seiner Abbil- 
dunssfunktion und damit seiner Aufgabe gerecht werden soll. 
Daraus folgt zwangsläufig, die Struktur der zur Auswertung vor- 
gesehenen Daten. (aktuelle wie archivierte) muß eine ständige 
inhaltliche Anpassung ermöglichen und gleichzeitig die Voraus- 
setzung dafür bieten, daß die dabei entstehenden ihrer Gestal- 
tung nach verschiedenen Teile des Datenbestandes bei geeigneten 
Auswertungssystemen die Forderung nach einer. kontinuierlichen 
Qualität der Auswertung erfüllen. 
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4. Die Auswertung als strukturelles Mehrebenenproblem 


Es existieren noch weitere Beziehungen zwischen Struktur und 
Auswertung. Das wird deutlich durch das Wechselspiel zwischen 
Nutzer und Informationssysten im Zusammenhang mit den zugehö- 
rigen Strukturebenen und den verschiedenen Phasen der Datenaus- 
wertung. 


Nutzer Auswertungsproblem reale Struktur der 
Krankenhausorgani- 
| J sation 
(Wirklichkeit) 


Informations- Auswertungsaufgabe ‚logische Struktur 
zentrale (AwA) y der Daten 


Eingabe Eingabedaten zur 
= : EDV-gerschten Dar- 
v stellung d. AwA 


|=| . 
er (meer eu x 
= Auswertungs— ! \naschinelle Bearbei- physische Struktur 
> I | tung der Daten 
L) ee 
S Ausgabedaten 
» (EDV-gemäße Darstel- 
a lung der Lösung der 
Hi Aw. 
N 
S — v | 
H| Informations- nutgzergerechte Darstellung 
gentrule der Lösung logische Struktur der 
ä % Daten 
Nutzer problembegogene. s 
Interpretation der a en 
ne (Problemlö- keit 


Der Übergang vom realen Auswertüngsproblem, wie es sich für den 
Nutzer stellt, zur Auswertungsaüufgabe, die die EDV-mäßigen Vor- 
aussetzungen berücksichtigt, entspricht einem Näherungsproblen. 
Die Existenz einer für den Nutzer akzeptablen Näherung wird in 
wesentlichen beeinflußt von 


- der in der logischen Struktur zum Ausdruck kommenden Gestal- 
tung des zur Auswertung vorgesehenen Datenbestandes 
(Inhalt, Umfang, Auswahl in Bezug zum Auswertungsproblenm), 

- der Struktur des Datenbestandes 
(Verfügbarkeit problembezogener Daten), 
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- der Leistungsfähigkeit des Auswertungssystens 
(Realisierung der Verknüpfungen und Därstellung). 


Diese Näherung hat ihre Inversion beim späteren Übergang von der 
EDV-Lösung der Auswertungsaufgabe zur realen Problemlösung, 

Auf den ersten Blick hat dabei die Gestaltung der Daten als 
Ausdruck des Informationsgehaltes, der Informationsfülle pri- 
märe Bedeutung, denn Je umfassender über bestimmte Prozesse in- 
formiert werden soll‘, um so umfassender müssen diese Prozesse 
durch Daten abgebildet werden. "Umfassend" bedeutet dabei aber 
nicht automatisch, daß eine Unzahl von Daten erfaßt und gespei- 
chert werden, im Gegenteil. Mangelnde Überschaubarkeit wäre die 
Folge, und damit wären die Daten so gut wie begraben, Die Ge- 
staltung der Daten wirä damit zum Optimierungsproblem. 


Ziel: Möglichst viel Information durch möglichst 
wenig Daten, 


Die Verfügbarreit, d.h. die Nutzbarmachung der Daten, ist aber 
wiederum nur über eine geelgnete Struktur und entsprechenden | 
Potenzen des Auswertungssystems möglich. Daten, die sich nicht 
unkehrbar' eindeutig adressieren lassen, ‚sind für die automati- 
sierte Informationsverarbeitung im allgemeinen wertlos. 
(Klartext, mehrdeutige Datenkodierungen)'. 


Andererseits aber gibt es unter den eindeutig identifizierba- 
ren Daten die Teilmenge der fehlerhaften Daten. Die, falls 

sie nicht vom Auswertungssystem erkannt werden, die Lösung 
einer Auswertungsaufgabe beträchtlich verfälschen können, 
Die.physische Struktur muß also die Potenz einer Wertung der 
Daten ermöglichen, denn das Weglassen der fehlerhaften Daten 
bedeutet einen Informationsverlust. Im ausgedruckten Zustand 
z.B. können bestimmte fehlerhafte Daten noch richtig interpre- 
tiert werden. Auch wiirde das bloße Weglassen dieser fehlerhaf- 
ten Daten beim Aufbau des Datenbestandes nicht den Sachverhalt 
richtig widerspiegeln, denn es würde ."ohne Angabe" bedeuten.- 


Zusammenfassend lassen sich aus dem Dargelegten einige konkrete 
Forderungen an die physische Struktur der zur an vor- 
gesehenen Datenbestände ableiten: 


1. Die physische Struktur aller vergleichbarer Datenbestände‘ 
muß identisch sein. (Dds heißt nicht, daß die jeweils konkre- 
te Datenorganisation identisch ist. Auch die logische Struk- 
tur muß nicht identisch sein.) 
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-2..-Die. Menge. der. Paten insgesamt und pro Bezugsebene- (z.B, 
Patientenaufenthalt) muß in bestimmten Grenzen (Hardware- 
Problem) beliebig veränderbar sein, 

3. Änderungen wie unter 2, dürfen nicht zur Veränderung der 
Identifizierungsadressen der nicht betroffenen Daten führen, 
(Sicherung der kontinuierlichen Qualität der Auswertung.) 

4. Für alle einzelnen Elemente der Datenmenge müssen umkehrbar 
eindeutige Identifizeirungsaäressen existieren. | 

5. Die Identifizierungsadressen sollten weitgehend aus dem 
Aufbau des Erfassungsmediums ableitbar sein. 

Logische Struktur = Datenorganisation 
(Hohe Überschaubarkeit, leichte Identifikation) 

6. Feste Satzlängen sind ungeeignet. 

(Leerer Speicherplatz, hohe physische Laufgeit, keine Er- 
weiterbarkeit über ein bestimmtes Maß hinaus) 

7. Fehlerhafte Daten müssen kennzeiohenbar sein. 


Im Projekt "FRIEDA" des Krankenhauses "Friedrichshain benützen” 
wir für die verschiedenen zur Auswertung vorgesehenen Datenbe- 
stände eine Struktur, die den wesentlichsten hier genannten 
Forderungen gerecht. wird., Alle bei.uns archivierten Datenmengen 
‘werden intensiv für die Lösung der verschiedensten Auswertungs- 
probleme genutzt. 


Verfasser: 

Dipl.-Math. Ing. Jürgen kelzer 
Städtigches Krankenhaus im Friedrichshain 
Organisations- und Rechenzentrum 

1017 Berlin 

Leninallee 49 
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Jantke, Renate 


Das ee MAS/D-0S 


1. Einleitung 
Die gegenwärtige Entwicklung 'bei der Bewältigung von Aufgaben 


in verschiedenen EDV-Anwendungsbereichen fordert die Beherr- 
schung einer Vielzahl informationstechnischer Einzelheiten. 
Daraus ergeben sich Forderungen an Datenverwaltungs- und Archi- 
vierungssysteme, die gleichartige Aufgaben, wie das Bereit- 
stellen von Speicherplatz für Datenmengen, den Zugriff zu Daten, 
das Archivieren und Yiederauffinden, zu lösen haben. 


Bei der Entwicklung und Implementierung des Datenverwaltungs- 
‚systems MAS/D-0S (Memory Administration System/Directory-0S) 
als weiterentwickelte Version eines Systems für die BESM6 wurde 
das Ziel verfolgt, ein abgestimmtes System von Funktionen be- 
reitzustellen deren einfache. Anwendung es gestattet, Daten- 
mengen effekiiv und rationell zu verwalten und. obengenannte 
Aufgaben zu realisieren. 


Das Datenverwaltungssystem ist ein effektives Hilfsmittel in 

der Anwendungsprogrammierung, speziell auch für dialogorientier- 
te Softwareentwicklung auf wissenschaftlich-technischem Gebiet 
geeignet. A 


Folgende Zielstellungen wurden bei der Entwicklung berück- 

sichtigt: 

- dynamische Bereitstellung von Speicherplatz für Datenmengen, 

- effektiver Zugriff zu Daten, d. h. schneller Direktzugriff 
und sicherer Zugriff zu den Daten über Zugriffsfunktionen, 

- nutzergesteuerte bzw. automatische Archivierung von Daten. 


Dabei unterliegen die Datenmengen keinen Restriktionen, was 
ihre Struktur und ihren Inhalt betrifft. 


Daraus ergibt sich die Möglichkeit, unterschiedlichste Infor- 
mationen zu verwalten und zu archivieren, sowie dieses System 
als Basis für die Verarbeitung strukturierter Datenmengen zu 
nutzen. \ 
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Durch eine geeignete Implementation ist das Datenverwaltungs- 
system MAS/D-0S in unterschiedlichen Programmiersystemen nutz- 
bar, in solchen mit Standardparametervermittlung OS/ES oder 
mit PASCAL 360 Parametervermittlung. 


2. Systemarchitektur 
Anhand der Systemarchitektur wird in folgenden die Arbeitsweise 


des Datenverwaltungssystens beschrieben. 


Die zugrunde gelegten logischen Informationseinheiten sind 
Files, die als unstrukturierte Datenmengen beliebiger Länge 
aufgefaßt werden. Sie eind unter einem Namen - Filenaine - 
identifizierbar und durch einen Status - Filestatus - charak- 
terisiert. Der Inhalt eines Files und sein Status sind von- 
einander unabhängig. Der Status steuert lediglich die Art und 
Weise der Arbeit des Systems mit diesem File. 


Notwendige Voraussetzungen für die Arbeit des Systems sind 
eine Direktzugriffsdatel, die zur Aufnahme archivierter bzw. 
temporär ausgelagerter Files dient und ein Hauptspeicherbe- 
reich, der als Arbeitsspeicher für die dynamische Bereitstel- 
lung bzw. Freigabe von Speicherplatz für Files dient. 


Auf diesen beiden Speicherbereichen sind Basisfunktionen, wie 
Erzeugen der Datenstruktur 

Operationen auf der Datenstruktur, 

Löschen einer Datenstruktur 

Statuseinstellung 

und Archivierungsfunktionen für die in der Abbildung: ange- 
gebenen Verwaltungsfiles erklärt, deren Gesamtheit für die 
interne Seite mit MAS/I und für die externe mit MAS/E be- 
zeichnet wird. 
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MAS/D-Datei 


an | 


Zugriff (über BD 


MAS/E - allgemeine Verwaltung 
Speicherverwaltung 
Katalogverwaltung 


| Imasyı allgemeine Verwaltung | 


Speicherverwaltung | 
Katalogverwaltung 


Die Verwaltungen für MAS/I und MAS/E sind logisch voneinander 
getrennt und werden als Files aufgefaßt. Aus den Basisfunk- 
tionen, die auf diesen beiden Speicherbereichen erklärt sind, 
werden die bereitgestellten Nutzerfunktionen abgeleitet. Da- 
durch entsteht eine übersichtliche Programmarchitektur, die 
günstige ‚Voraussetzungen für Änderungen bzw. Erweiterungen 
schafft. 2 


Für folgende Prinzipien, die das Datenverwaltungssystenm 
MAS/D-OS charäkterisieren, stehen dem Nutzer Funktionen und 
Beschreibungsmittel zur Verfügung, auf die im nächsten Ab- 
schnitt hingwiesen wird. 


- Für Files belieber Länge wird auf Anforderung Speicherplatz 
im Arbeitsspeicher bereitgestellt. Die Bereitstellung erfolgt 
entsprechend einem festgelegten Status (Iadestatus) in drei 
Formen: 
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(1) Zusammenhängender Speicherplatz wird bereitgestellt 
(sequential allocation). 

(2) Speicherplatzbereiche, die über Referenzen verkettet. 
sind, werden bereitgestellt (linked allocation). 

(3) Es wird nur ein Speicherbereich fester Länge bereitge- 
stellt, auf dem eine virtuelle Arbeitsweise durchge- 
führt wird (segmented allocation). 


Die dynamische Verwaltung von Speicherplatz für Daten- 
mengen, unterstützt insbesondere. Anwendungen, bei denen 
der Bedarf an Speicherplatz erst während der Laufzeit von 
Programmen ermittelt wird. 


- Files, die zu einem späteren Zeitpunkt wieder benötigt 
werden, können während der Laufzeit oder durch Abschluß 
der Arbeit in einer MAYD-Datei auf einem externen Speicher 
archiviert werden. Nach erneuter Eröffnung der Arbeit mit 
dem System, stehen die archivierten Files zur weiteren Ver- 
arbeitung zur Verfügung. 


- Der Zugriff zu Daten im File wird zweifach unteratützt. Zum 
einen ist es möglich zm Pileinhalt direkt zuzugreifen, zum 
anderen erfolgt der Zugriff über Zugriffsfunktionen. Durch 
den Direktzugriff wird ein schneller Zugriff realisiert. 
Allerdings fallen hier Kontrollen auf Zugriffsrechte, File- 
und Speichergrenzen weg, die beim Zugriff über Funktionen 
durchgeführt werden. 


3. Nutzerschnittstellen 
Sämtliche Funktionen des Systems MAS/D-0S stehen dem Nutzer 


als Unterprogramme zur Verfügung. 

Die Strukturierung der MAS/D-Datei und die Initialisierung 
des Systems erfolgt durch eine allgemeine Funktion, die ein- 
malig anzuwenden ist. 


Den Rahmen für. sämtliche Funktionen, die das Datenverwaltungs- 
system bietet, bilden eine Funktion zum Eröffnen der Arbeit 
und eine Funktion zum Abschließen der Arbeit. Innerhalb dieses 
Rahmens sind Zugriffs-, Auskunfts-, Bibliotheks- und andere 
Funktionen des Systems nutzbar. 


466 


Kit Hilfe von Filefünktionen kann man Files anlegen, ihren 
Status festlegen und Files nutzergesteuert laden bzw. ent- 
laden (archivieren). Die Zugriffsfunktionen lagern, falls es 
notwendig’ist, Files prioritätengesteuert aus und laden be- 
nötigte Files automatisch in den Arbeitsspeicher. Über Aus- 
kunfts- und Bibliotheksfunktionen erhält man Angaben über die 
Charakteristika eines Files und der MAS/D-Datei. Bereitge- 
stellte Änderungs- und Kopierfunktionen erweitern das Spek- 
trum der Nutzerfunktionen. Mit dem Datenverwaltungssysten 
UAS/D-0S steht dem Anwendungsprogramierer ein leistungs- 
fähiges System als Hilfsmittel zur effektiven Softwareent- 
wicklung zur Verfügung. : 
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Verfasser: 
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Programme zur Leistungsbewertung im DVZ Dresden 


ipl.-Ing. Elke Schreiber 
Technische Universität Dresden 


+. Einführung 


In dem Maße,wie sich der Einsatz von Rechentechnik zur Lösung 

volkswirtschaftlicher Belange erhöht,gilt es den Datenverar- 

beitungsprozeß im Rechenzentrum noch stärker zu rationalisie- 

ren.Vor allem. sind die für die Abarbeitung von Massen- 

datenprojekten bereitgestallten Ressourcen effektiver zu nut- 

zen.Zur Beseitigung der Diskrepanz zwischen den verfügbaren 

Resnourcen und ihrer Nutzung wurden zwei Programmsysteme im- 

plementiert mit dem Ziel der Bilanzierung und optimalen Ab- 

arbeitung von ırojekten im DVZ Dresden; 

1.Das Programm,ystem SMFSTA zur. Leistungsmessung von Arbeits 
lasten 

2.Das Programmsystem MAPA zur Leistungsverbesserurg durch 
Jobnetzoptimierung . 

2. Verhaltensmodelle 


Grundlage der Leistungsbewertung von Rechnerinstallationen 
bilden sogenannte Verhaltensmodelle.Sie erfassen den quan- 
titativen Zusammenhang zwischen unabhängigen Einflußgrößen 
und Bewertungsgrößen und seiner Arbeitslast durch entspre- 
chende Kenngrößen.Wesentliche Bewertungsgrößen sind: 
--die Systemleistung L (Arbeitseinheiten/ZE) 
- der Leistungsfaktor R 
Zu den unabhängigen Einflußgrößen zählen: 
- die Arbeitslast,wie sie durch die Vielzahl von Ressour- 
cenanforderungen repräsentiert wird 
- die Konfiguration,als Ausdruck verfügbarer Ressourcen 
je Geräteklasse 
- sonstige Faktoren,z.B. die Ressourcenzuteilungsstrate- 
gie,wie sie in der Ablaufplanung genutzt wird. 
Das Ausgangsmodell der Leistungsanalyse des Multiprogranmn- 
betriebes beschreibt die Abhängigkeit des Leistungsfaktors 
R von bestimmten Einflußgrößen.R gilt als Maßzahl für die 
Bedienzeit eines Jobstapels über die Laufzeiteinheit des 
Rechners: 
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x ur ‚mit 
T) ‚der Summenbedienungszeit aller Jobs und Tn ‚der Beschäf-. 
tigungszeit des Jobstapels. 


Es handelt sich dabei um ein Zweistufenmodellt: 

1. Stufe : Modell der festzugeordneten Ressourcen 
_2. Stufe : Modell der geteilt genutzten Ressourcen, 
3. Modell der festzugeordneten Ressourcen 
’ 
"Das Modell der festzugeordneten Ressourcen kann durch folgende 
Formel beschrieben werden : 

4 = f(m,E(N),P), 

Danach ist der Multiprogrammfaktor M eine Funktion des’ Kon- 
figurationsvektors m,des Arbeitslastvektors E(N) und der 
Reihenfolge der Jobbedienung P,wie sie im Ablaufplan fest- 
gelegt iet.Der Konfigurationsvektor 


n = (ng,Mp,MyMy) 

widerspiegelt die Zahl der festzugeordneten Ressourcen| m, der 
Klasse Ä.Dabei gilt LECK {S,P,B,D } ‚wobei folgende Geräte- 
klassen berücksichtigt werden: 

S - Hauptspeicherplatz 

P - Yagnetplattengeräte 

B - Magnetbandgeräte 

D - Drucker. 

Der Multiprogrammfaktor M ist fir eine vorgegebene Geräte- 
konfiguration und ein vorgegebenes Aufgabenprofil nach oben 
begrenzt[1].Die ressourcenbedingte obere Grenze HM, ergibt 
sich wie folgt: 

u, = Min i 

£n,) 

Über die Bestimmung von H, ergeben sich Möglichkeiten der 
Leistungserhöhung durch Anpassung der Arbeitslasten an vor- 
handene Konfigurationen.Die gewonnenen Ergebnisse sind Be- 
standteil der Kapazitätsplanung und nicht Gegenstand dieses 
Artikels. 

Das Programmsysten SMFSTA dient der Erfassung und Auswertung 
von SMF-Daten und liefert Eingangsgrößen für das Progrann- 
system HAPA.Boide Programmsysteme .leisten..einen.wesentlichen:: 
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Beitrag zur Leistungsverbesserung durch Jobnetzoptimie- 


rung von Datenverarbeitungsprojekten, 
4. Meßwertauswertung von SMF-Daten 


Grundlage der Auswertung bildet die Erfassung der Ressourcen- 

nutzung für drei Projekte der Tagesverarbeitung nach jedem 

Job- bzw.Jobschrittende in sogenannten SMF-Datensätzen auf 

einer Plattendatei. Von dieser Plattendatei werden täglich Band - 

abziüge erstellt,und die Sammlung von Bandabzügen Über einen 

Monat wird der statistischen Auswertung zugrunde gelegt. 

Ziel ist: 

- die Ermittlung geeigneter Normativwerte als Eingangsgrö- 
Ben für die Jobnetzoptimierung von Projekten 

- din Bereitstellung von Meßwerten zur Bilanzierung der Pro- 
jJekte im DVZ Dresden. 

Die xealisierung übernimmt das PS SMFSTA,das parameterge- 

steuert die Auswertung von SMF-Deten vornimmt und die sta- 

tistischen Grt?ien in Form von Erwartungswerten und Vertei- 

lungsfunktionen beschreibt.Den problemorientierten Programn- 

ablaufplan de Programmsystems zeigt Abb.1. 

Statistische Größen,die aufbereitet und verdichtet werden, 

sind u.a.: 

- Jobverweilzeiten 'DJVZ 

- Belastungsgrößen je Job HSM (Hauptspeicher-K-Byte-Minuten) 

- Ressourcenbedarf der Jobs GERM (Geräteminuten pro Gerätetyp) 

Eine Auswahl der pro Job ermittelten Normativwerte über sta- 

tistische Größen für bestimmte Gerätetypen zeigt Tabelle 1 

Die gewonnenen Meßwerte bilden die Grundlage für die Bestim- 

mung der Teillasten E(N,) bei der Kapazitätsplanung. 

Darüberhinaus liefert das PS SMFSTA Normativwerte der Jobver- 

weilzeit,der Belastungsgrößen und des Ressourcenbedarfs der 

Jobs für das PS MAPA,einem Programm zur Jobnetzoptimierung 

von Datenverarbeitungsprojekten. 

5, Leistungsverbesserung durch Jobnetzoptimierung 


Ziel der Jobnetzoptimierung ist die Maximierung des Leistungs - 
faktors R bei der Abarbeitung von Projekten im Stapelbetrieb,. 
Über eine optimale Gestaltung der Jobnetze,die den Projekten 
zugrunde liegen,wird eine Erhöhung des Multiprogrammfaktors 
nöglich. 

Ausgangspunkt der Untersuchungen ist die Erstellung eines op- 
timalen Ablaufplans der Projektabarbeitung unter Beachtung für 
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der Jobabhängigkeiten und der festzugeordneten. Ressourcen. 
Zur Lösung dieser Aufgaben werden Algorithmen der Netzplan- 
technik mit beschränkten Ressourcen und Algorithmen der 
Strukturtheorie (erweitertes Matrizenkalkül) zur Bestimmung 
der Jobabhängigkeiten im PS MAPA genutzt.In Abb.2;'ist die 
Grobstruktur des Programmsystems beschrieben, 
Über die Ermittlung der Ein-und Ausgabedatein der Jobs aus &u 
den Job-und Prozedurbibltotheken lassen sich Vorgänger-und 
Nachfolgerelation der Jobs des Jobnetzes bestimmen. Diese.iBr- 
gebnisse werden in Matrizenform abgespeichert.Zur Beschreikur 
bung der Struktur solcher Netze werden die aus der Netzplan- 
technik bekannten Vorgangsknotennetze verwandt.Für ein, ein- 
faches Jobnetz 1s8t die Abhängigkeitsrelation in Abb.3 darge- 
stellt. 
Die Ausgabe der Jobabhängigkeiten durch das Programmsysten 
geschieht in verbaler Form. 
Ausgabe der Jobabhängigkeiten: 
JOB A hat als Nachfolger JOB B 
JOB J 
JOB B hat als Nachfolger JOB C 
JOB C hat als Nachfolger JOB D 
JOB E 


JOB N hat keinen Nachfolger 


Treten innerhalb des Netzes transitive Überbrückungen auf, 
so können diese durch Matrizentransponierung mit nachfolgen- 
der Abwärtsiteration beseitigt werden. Theoretische Grundla- 
gen liefert dafür die angewandte Strukturtheorie[2]. 
Voraussetzung für die prioritätsgesteuerte Abarbeitung der 
Jobs ist eine Rangbestimmung.In Anlehnung an einen Algo- 
rithmus der Netzplantechnik[3]erfolgt nach einem bestimn- 
ten Modus eine Manipulierung der Zeilen-und Spaltenelemen- 
te der Vorgänger-Nachfolgematrix,in deren Ergebnis jeder 
Job einem Rang zugeordnet wird. Parallel abzuarbeitende Jobs 
gehören einem Rang an ( Abb.3). 

Unter Berücksichtigung festzugeordneter Systemressourcen 
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erfolgt eine Eingliederung sämtlicher Jobs nach entsprechen- 
den Prioritätskriterien in einen terminierten Ablaufplan.Die 
Optimierung erfolgt rangweise,so daß Jobs des 1. Ranges höch- 
ste Priorität-aufweisen.Innerhalb der Jobs eines Ranges er- 
folgt eine weitere Prioritätsauswahl: 
- Jobs,die im nächsten Rang einen- Nachfolger 'haben, erhal- 
ten Abarbeitungsvorrang vor denen ohne Nachfolger 
- Jobs mit längster Restverweilzeit erhalten höchste Prio- 
rität . 
Es erfolgt eine weitere Prioritätssetzung bei der Einglie- 
derung der Jobs in den terminierten Ablaufplan.Dabei wird ge- 
prüft,ob eine Einordnung in die hauptspeichergüinstigste Par- 
tition möglich ist,sonst vird der Job in die pufferzeitgünstig- 
ste Partition eingeoränet. 
In Ereebris druckt das PS'MAPA einen Partitionbelegungs- 
plan,aus dem der Operator die Reihenfolge der Jobabarbei- 
tung,die dafür aufzuwendende zeit [min]una die Belegung der 
Verarbeitungspsrtition erkennen kann, 
Das PS MAPA wurüe an spezifischen Projekten im DVZ Dresden S\ 
erprobt und bi achte Laufzeiteinsparungen von 6r015%.Ein Ver- 
gleich der Multiprogrammfaktoren M und Leistungsfaktoren R 
in Tabelle 3 zeigt für’ drei konkrete Projekte eine erheb- 
liche Leistungsverbesserung bei den optimierten Varianten, 
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Tabelle 1: Normativwerte über statistische Größen für 
bestimmte Gerätetypen. 


EEE 


Tabelle 2 ı Leistungeverbesserung konkreter Projekte 


Projekte 


a74 
Partitionbelegungsplan 


Tabelle 3 
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Abb. 1 Problemorientierter Programmablaufplan des PS SMPSTA 


Eingabe der Nutzerda- 
ten(Paramstrisierung) 


Zugriff zu den SUP- 
daten, Syntaxkontrolle 


Berechnung und Auf- 
zeichnung der Meßnerte 


Tabellendruck stati- 
|.stischer Größen 


Druck der Häufigkeits 
verteilung für ausge- 
wählte Jobs und Größen 


Abb. 
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Grobstruktur des PS MAPA 


Ermittlung der Vorgän- 
ger-Nachfolge-Relation 
der Jobs 


Matrizentransponierung 
und Abwärtsiteration - 


Rangfolgebestimmung 
der Jobs 


Ressourcenoptimierung 


Abb, 3 
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Abhängigkeitsrelation eines Jobnötzes 
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Verfahren zur Automatisierung der Verarbeitungstechnologie 
1. Ansprüche an eine moderne EDV-Technologie 


Bei der Entwicklung von Verfahren zur Automatisierung der Ver- 

arbeitungstechnologie wurde von folgenden Ansprüchen ausgegan- 

gen, die heute an eine moderne EDV-Technologie gestellt werden: 

- den Anwender weitestgehend von Problemen der Verarbeitungs- 
technologie zu befreien 

- im Rechenzentrum den Produktionstechnologen und Maschinen- 
bedienern betriebssichere, einfache und einheitliche techno- 
logische Hilfsmittel in die Hand zu geben 

- die Auftragsbearbeitung im Rechenzentrum zu rationalisieren 
und die vorhandene EDVA mit hoher Effektivität zu nutzen 

- die Programmtestung und Erprobung unter Produktionsbedingun- 
gen durchführen zu können 

- Möglichkeiten tär einen vom Anwender gesteuerten Dialogbe- 
trieb vorzuseher. 


2. Das allgemeine Steuerprinzip der Stapelverarbeitung 


‘ 


Eine Methode der Verscbeitungstachnolsdie ist die Stapelver- 
arbeitung. Das Prinzip der Stapelverarbeitung besteht darin, 

daß in einem sogenannten Anwendungsfall die Nutzung eines Pro- 
jektes durch’ die Anwendung bestimmter problemorientierter Systenm- 
unterlagen (im folgenden kurz POS genannt) auf anwendungsfall- 
eigene Datenbestände erfolgt. 

Jede Projektnutzung für einen Anwendungsfall wird als Arbeits- 
auftrag formuliert und besteht neben manuellen Arbeiten zur Dse- 
tenbereitstellung. und ähnlichem vor allem aus Operationen, die 
auf der EDVA unter der Steuerung eines Steuerprogramms im Rahmen 
eines Jobs in einem oder mehreren Jobschritten zur Ausführung 
gelangen. Solche Operationen sind z.B. Pflege, Rechnung, Listung. 
Die Operationen werden vom Anwender vorgeschrieben und durch die 
Angabe von Parametern in’ ihren Funktionen gesteuert. 

Zur Einsparung von .Anlagenkapazität, zur Vereinheitlichung der 
Parameterübergabe für die Operationen, zur Vereinfachung der 
Programmierung und der Technologie der Nutzung von POS wurde 

ein allgemeines Steuerprinzip erarbeitet, 
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Die Ausführung einer ‚Operation einer POS wird durch eine soge- 
nannte Operationsanweisung veranlaßt. Die Operationsanweisung 
hat den folgenden prinzipiellen Aufbau: 
./[nane] operation operanden 
name - wahlfrei, kann zur Kennzeichnung der Operationsan- 
weisung im Protokoll benutzt werden 
operation - Angabe der Operation aus einer POS 
z.B.: Datenpflege, Rechnung, Listung 
operanden - Schlüsselwort- oder Stellungsparameter, 
dienen zur Steuerung der Operation und zur Defini- 
tion der zu verwendenden Datenbestände 
z.B.: Geheimhaltungsgradangaben für Drucklisten, 
zu verwendende Pakete von Rechenformeln, 
Auswahlbedingungen, 
Datenbestandsnamen 
Für die wiederholte Abarbeitung einer Folge von Operationsan- 
weisungen kann diese Folge zur Vereinfachung für den Anwender 
zur Makrooperation zusammengefaßt werden. Makrooperationen kön- 
nen vom Anwender selbst definiert werden und haben den folgen- 
den Aufbau: 
% [name ] moper operanden 


name - 8. 0%. 
moper - Name der Makrooperation 


operanden - Parameter, die durch die Makrooperation an die in 
ihr enthaltenen Elementaroperationen weiterge- 
reicht werden 


Funktionen des allgeneinen Steuerprinzips 


- Operationsanweisung bewirkt die Abarbeitung eines Programmes 

- Verarbeitung von Makrooperationen möglich, indem diese in 
Elementaroperationen überführt werden 

- auf Operationsanweisungen können unmittelbar Subanweisungen 
zur Steuerung der Operation oder Daten folgen, sofern die 
entsprechende Operation das vorsieht 

- bedingte Abarbeitung in einer Folge von Operationsanweisungen 
durch die Auswertung des erfolgreichen Abschlusses der vor- 
hergehenden Operationsanweisungen oder des Zustandes der zu 
verwendeten Datenbestände möglich 
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- Wiederanlauf im Falle eines Abbruchs der Verarbeitung eines 
Auftrages möglich 

- syntaktische Kontrolle der Operationsanweisungen ohne Abar- 
beitung der Programme möglich 


Für die Realisierung des beschriebenen Steuerprinzips sind die 
folgenden ausgezeichneten Anweisungen notwendig: 
.»+ NAME name 
zur Vorbereitung der Wiederanlaufmöglichkeit 
e+ RESTART name 
zur Ausführung des Wiederanlaufs 
.+ PARM parameter 
zur Parameterübergabe an das Steuerprogramm 
z.B. Geheimhaltungsgrad des Ablaufprotokolls, 
Bedingungen für den Abbruch der Verarbeitung 


Für die Nutzung der Wiederanlaufmöglichkeit ist die Bereit- 
stellung eines Rı ferenzspeichers Voraussetzung. 


Beispiel für eine Folge von Steuer- und Operationsanweisungen: 


«+ NAME RSANW werden vom Technologen im RZ 

.+ PARM C=12,6GN=NFD hinzugefügt 

./ ADD EIN=x Operationgsanwei- 
° Kartenstapel, der von.ADD verar- sungen eines Auf- 


beitet werden soll trages, stammen 


vom Anwender 
./ PFL  EIN=STAMM,AUS=LST@1,VAR=(A,B) 
./ RECH EIN=LST1 „AUS=AUS ,FPAKA=(FPAK5999 ‚GAUSW=(5)) 
./ LIST EIN=AUS P: 


Das allgemeine Steuerprinzip der Stapelverarbeitung ist nun 
die Grundlage für zwei Regime der Verarbeitungstechnologie. 
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allgem. Steuerprinzip der Stapelverarbeitun 


‘ 


Basistechnologie Generierungstechnologie 
Steuerprogramm: BATCH 


Vorphase 
Steusrprogramm: BGEN. 


Hauptphase 
Steuerprogramm: BTCH 


3. Basistechnologie 


Dieses Regime ist dadurch ausgezeichnet, daß der Anwender für. 
einen Arbeitsauftrag einen komplett zusammengestellten Job be- 
reitstellt, der unmittelbar auf der EDVA abgearbeitet werden 
kann. Ein solcher Job hat z.B. das folgende Aussehen: 
/JIRECHBL :30B 2... 
//ISTEPß1 EXEC PGM=BATCH 

/ISTEPLIB DD... 

//BASPRINT DD .. 

//BHREFSS DD .. 

/IBALIST DD .. 

/1WS | D .. 

//S®RTOUT DD ... 

//BASIN DD 

./ RECH EIN=SORTOUT ‚AUS=AUS ‚FPAKA=(FPAK5999 ‚GAUSW=(5)) 


Vom Technologen werden dann nur noch die PARM- und NAME-Anwei- 

sungen: hinzugefügt, falls es erforderlich ist. EN “2 

Dieses Technologieregime hat aber folgende Nachteile: 

. Anwender muß sämtliche Jobsteueranweisungen liefern 

. Problem der richtigen Zuordnung von Datenbeständen zu Daten- 
trägern bei einer Vielzahl von Datenbeständen und mehreren 
Generationen 

. Bezugnahme auf Datenbestände nur über die Angabe der bereit- 
gestellten Jobsteueranweisungen 
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. Bedingte Ausführung von Operationsanweisungen nur in Abhängig- 
keit von der erfolgreichen Bearbeitung vorhergehender Anwei- 
sungen; Auswertung des Datenbestandszustandes nicht möglich 


Daraus ergibt sich, daß die Basistechnologie nur für die Be- 
arbeitung von aus technologischer Sicht anspruchslosen Projekten 
mit wenigen, kaum wechselnden Datenträgern und für vom Program-. 
mnierer betreute Testrechnungen eingesetzt werden sollte. 


4. Generierungstechnologie 


Um die Nachteile der Basistechnologie zu beseitigen, wurde die 
Generierungstechnologie entwickelt. In diesem Regime sind vom 
Anwender nur die Operationsanweisungen bereitzustellen. Die Ge- 
nerieringstechnologie unterteilt sich in zwei Phasen. 


4.1. Vornhase BGEN 


Mittels BGEN wird der gesamte vom Anwender bereitgestellte 

Eingabestrom den folgenden Bearbeitungsschritten unterzogen: 
Auflösung von M-krooperationen in Elementaroperationen, sofern 
welche vorhanc .n sind . 

- Syntaktische ‘analyse der Operationsanweisungen 

- Überprüfung auf Zulässigkeit und Vollständigkeit der Parameter 
zu technologischen Angaben, 

- Überprüfting auf Zulässigkeit und Existenz benötigter Speicher 
- Erzeugung benötigter Jobsteueranweisungen in einem oder mehre- 
ren Jobschritten und Zuordnung der Operationsanweisungen zu 

den Jobschritten 
- Formatisierung eines Registrierobjektes im Referenzsepeicher 
- Erzeugung einer Jobbeschreibung für den in der Phase_BTCH zu 
startenden Verarbeitungsjob 
Bei BGEN erfolgen noch keine Manipulationen mit den Datenbestän- 
den. 


4.2. Hauptphase BTCH 


In dieser Phase erfolgt unter dem Steuerprogramm BTCH die Ab- 
arbeitung der Operationsanweisungen mit dem in der Vorphase ; 
BGEN erzeugten Job. 

Entsprechend den in den Operationsanweisungen enthaltenen tech- 
nologischen Angaben weist BTCH den Verarbeitungsprogrammen die 
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zu verwendenden DD-Namen für die Jobsteueranweisung, durch 
die die zu verarbeitenden Datenbestände definiert werden, zu. 
Unter dem Regime der Generierungstechnologie wird für jeden 
Datenbestand eine. sogenannte Datenbestandscharakteristik auto- 
matisch geführt. In ihr werden unter anderem vermerkt: 
Name und Nummer der Operationsanweisung, durch die der Be- 
stand erstellt oder gepflegt wurde, 
inhaltlicher und technischer Zustand des Bestandes 
. Name der Däateibeschreibungstafel für den Bestand 
. Sortierung des Bestandes 
. Anzahl der Datensätze 


BTCH unterstützt die Verarbeitungsprogramme weitestgehend bei 
der Auswertung und Pflege der Datenbestandscharakteristik und 
übernimmt gegebenenfalls automatisch eine benötigte Vor- oder 
Nachsortierung der Datenbestände. 
BTCH registriert laufend den Bearbeitungszustand und ermöglicht 
dadurch einen automatischen. oder gesteuerten Wiederanlauf der 
Abarbeitung der Operationsanweisungen. 
Die Vorteile der Generierungstechnologie gegenüber der Basis- 
technologie bestehen nun im folgenden: 
. Anwender muß nur die Operationsanweisungen liefern 
. die Zuordnung von Datenbeständen zu Datenträgern und die Er- 
zeugung der Jobsteueranweisungen erfolgt automatisch 
. in den Operationsanweisungen kann nur durch die Angabe des 
Datenbestandsnamens bzw. des Speichernamens Bezug auf die 
Datenbestände genommen werden 
. durch die Datenbestandscharakteristik 
- Steuerung der bedingten Ausführung von Operationsanweisun- 
gen durch die Auswertung des Zustandes der Datenbestände 
- Reduzierung der Rechenzeit durch Vermeidung unnötiger 
Datenbestandssortierungen 
- bessere Überwachung des Bearbeitungszustandds von Arbeits- 
aufträgen 


Voraussetzung für die Arbeit im Regime der Generierungstechnolo- 
gie sind: 
die Bereitstellung eines Referenzspeichers 
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die Definition von Speichern mittels des Systems DAMODASS 
die Bereitstellung eines sogenannten Anwendungsfallmoduls 
zur Konkretisierung allgemeiner technologischer Anforderun- 
gen i 


Verfasser: 
Dr. Hörst Sadowski, Berlin 
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Dipl.-Math. Günther Kroß, Humboldt-Universität 


SPOOL 2,0 - System zur Unterstützung eines zeitweise bedienungs- 
unabhängigen Betriebes an ESER-Rechnern 


1. Vorbemerkungen 


Das System SPOOL 2.0 ist eine ab Januar 1982 verfügbare Version des 
Systems SPOOL, dessen Ziel die Rationalisierung und Automatisierung 
der Produktion an Rechenzentren mit ESER-Anlagen ist (vgl. /1/) 
SPOOL 2.0 ist als Betriebssystemkomponente unter den Steuerprogrami- 
konfigurationen MVT und MFT des OS/ES einsetzbar. Die speziellc 
Zieistellung für dieses System ist die Ermöglichung eines bedie- 
nungsarmen bzw. eines zeitweise bedienungsunabhängigen Betriebes der 
EDVA und somit insbesondere eine Steigerung der Arbeitsproduktivität 
hinsichtlich 'des Verhältnisses von Bedienungsaufwand (Anzahl der Be- 
dienkräfte) zu Produktionsvolumen (produktive Laufzeit). Das Systen 
geht von dem Grundgedanken aus, die Erreichung dieses Zieles durch 
eine Erleichterung der Bedienarbeit, durch eine Konzentration der 
Bedienarbeit auf bestimmte Zeitintervalle und damit verbunden durch 
die Schaffung von Intervallen bedienungsunabhängiger Produktion zu 
unterstützen. Dabei wird davon ausgegangen, daß bedienungsunabhängi- 
ge Zeiten, also die Zeiten in denen die Produktion an der EDVA ohne 
Bedienereingriff gesichert ist, ohne zusätzliche Belastung anderer 
Bereiche des Rechenzentruns, wie z,B, die Arbeitsvorbereitung und 
bei einem normalen Stapeljobprofil, also z.B. nicht notwendig nit 
länger laufenden Jobs, für täglich mehrere Stunden zu gewährleisten 
sinds 


Gegenüber seinen Vorgängerversionen besitzt das System SPOOL 2.0 
einige neue, seine speziellm zusätzlichenfunktionen realisierende 
Komponenten, Das System ist in dör Lage, in verschiedenen Betriebs- 
weisen, die sich vor allem hinsichtlich der Jobauswahl, dar Konso« 
lenunterstützung und der Bedieneraktivität unterscheiden, zu arbel- 
ten. Voraussetzung für die Gewährleistung der unterschiedlichen Be= 
triebsweisen ist dabei eine Jobklassifizierung hinsichtlicü deren ° 
Bedienanforderungen. 
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SPOOL 2.0 unterteilt die eingelesenen Jobs in die drei im folgenden 
aufgeführten, sich hinsichtlich der Bedienanforderungen unterscliei=- 
denden Kategorien: 


a) bedienungsunabhärgige Jobs: 
- Keine Magnetbandarbeit, 
- Keine Benutzung von mehr als zwei privaten Mognetplatten, 
Kein Direktanspruch peripherer Geräte, 
Keine Modifikation verfallsgeschützter Dateien, 
Keize Bedienerkommunikation; 
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b) beuingt bedienungsunabhängige Jobs: 
wie a), wobei :usätzlich erlaubt sind 
- Arbeit mit pr.vaten Magnetbändern, 
- Arbeit nit .ehr als zwei privaten Magnetplatten; 


c) bedienungsabbängige Jobs: 
Komplementärmenge zu a) und b). 


Die Jobklassifizierung erfolgt mittels der Analyse der durch die 
Nutzer in. ihren Jobs bereitzustellenden SPOOL-Steueranweisungen 
/#JOBPARM und /sSETUP. In ihnen müssen die benötigten Magnetda- 
tenträger, die direkt angesprochenen Geräte, die zu modifizierenden 
verfallsgeschützten Dateien und gsf. die Verwendung von WTOR's im 
Job angegeben werden. 


2.2. Betriebsweisen des Systens SEOOL_ 2.0 


Über ein Kommando der SPOOL-Kommandosprache ansteuerbar ist das Sy- 
sten in der Lage, in drei Betriebsweisen zı arbeiten: 


Bil: Abarbeitung von bedienungsabhänsigen und bedingt bedienungsunah- 
hängigen Jobs; 

32: Abarbeitung von bedienungsunabhängigen Jobs sowie derjenigen be- 
Jingt bedienungsunabhängigen Jobs, deren “agnetdatenträger mon- 
tiert sind (liOUNT für private Magnetbänder) und. ie mittels ei- 
nes Kommandos als bedienungsunabhängig ‚gekennzeichnet wurden; 

B3: Abarbeitung der Jobs unabhängig von deren Klassifizierung. 
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Allen Betriebsweisen gemeinsam ist eine magnetplattenabhänpize Job- 
auswahl. Es können generell nur solche Jobs zur Verarbeitung ausze- 
wählt werden, die entweder keine privaten Wagnetplatten verwenden 
oder deren Magnetplatten dem System über ein spezielles Kommando 
als logisch verfügbar mitgeteilt wurden und die in der praktischen 
Verfahrensweise i.a. vorher auch physisch _montiert wurden. Diese 
magnetplattenabhängige Jobauswahl erleichtert die Bedienung -und 
beugt Brdienfehlemund den daraus gegebenenfalle resultierenden 
Wartezuständen bei Montageanforderungen vor. Während der Betriebs- 
weisen B1 und B3 ist es nöglich, die Datenträserabhängiskeit der 
Jobauswahkl per Kommando zu entaktivicren. 


Standardtetriebsweise ist die bedienungsabhängige Betriebsweise 31, 
In ihr werden nur Jobs abgearbeitet, von denen angenomnen wird, daß 
sie Bedienanforderungen hervorrufen. Bedienungsunabhängige Jots 
werden nicht ausgewählt. Diese können somit während der Betriebs- 
weise Bl für einen bevorstehenden bedienungsunabhängigen Betrieb 
zurückgehalten werden. 


Eine bedienungsunabhängige Arbeit der EDVA ist durch Anwendung der 
bedienungsunabhängigen Betriebsweise B2 möglich. Während dieser 
werden vom System SPOOL 2.0 nur die Jobs zur Verarbeitung ausge- 
wählt, deren Nagnetplatten verfügbar sind und die keine Bedienan- 
forderungen hervorrufen. Das sind bedienungsunabhängige Jobs und 
diejenigen bedingt bedienungsunabhängigen Jobs, für die der Bedie- 
ner vor der Aktivierung der Betriebsweise B2 eine Bedienungsunah- 
hängigkeit sichern kann,wie z.B. durch MOUNT-Kommandos für die be- 
nötigten privaten Nagnetpänder. Während der Betriebsweise B2 sind 
sämtliche langsamen und. bedienungsintensiven E/A-Geräte wie Karten- 
leser, Drucker. u.a, inaktiv. Die Druckausgabe der Jobs wird mit 
entsprechenden Listenkennzeichen zur späteren Separierung während 
der Betriebsweisen Bi oder B3 versehen auf einem liagnett:-und zwi- 
schengespeichert, Die Kommunikation Betriebssysten - Konsole wird- 
durch ein spezielles Konsolinterface übernommen. Dieses Interface 
analysiert sämtliche Konsolnachrichten und übernimmt eine gegebenen- 
falle notwendige Beantwortung. Dabei werden Jobs, die Bedienanfor- 
derungen nervorrufen durch CANCEL aus dem System entfernt. betrof- 
fen werden können daüurch i.a. nur soiche Jobs, dic unvollständize 
Angaben in den SPOOL-Steueranweisungen haben. Die Arbeit der Kon- 


ARR 


sole selbst wird dadurch weitgehend entaktiviert, daß bis auf 'spe- 
zielle Systemnachrichten und Antworten auf Bedienerdisplaykomwendos 
sämtliche Nachrichten lediglich in das Systemprotokoll auszegeben 
worden. 


2.3. Übergang_zur. bedienungsunabhängigen Betriebsweise 


Der Übergeng von einer bedienungsabhängigen Betriebsweise (B1, P3) 
zur bedienungsunabhängigen Betriebsweise B2 wiräü durch ein Kommando 
($TS FREE) initiiert und durch einen wechselseitigen Konrunikations- 
und Handlungsprozeß SPOOL-Sediener realisiert. Alle notwendigen 
Maßnahmen werden vom System angefordert und überprüft, um eine dar- 
auffolgende reibungslose und effektive bedienungsunabhängzige Arbeit 
zu garantieren. Bei der folgenden Skizzierung des Umschaltprozesses 
bezeichne B, eine Bedienerhandlung und $, die Handlungsfolge von 
5?00L 2.0. 


34: Kommando $T‘.,FREE ; 

5]: - Stoppen der Jobauswahl und der SPOOL-E/A-Geräte (LKL, PD usw.); 
- Warten auf die Beendigung der Abarbeitungsphase ggf. noch ak- 

tiver bedienungsabhängiger Jobs; 

- Initiierung einer Bedienerinformationsliste (Kommando $L). 

0° Steuerung der Ausgabe der Bedienerinformationsliste, die jobbe- 
zogenen Angaben wie Datenträger, Geräte, zu überschreibende ver- 
fallsgeschützte Dateien u.a., sowie magnetplattenbezogenen Anga- 
ben wie Anzahl der sich auf eine Magnetplatte beziehenden Jobs 
und Gesantlaufzeit dieser Jobs (unterteilt nach Bedienungsabhän- 
gigkeit bzw. Bedienungsunabhängigkeit) enthält und somit geeig- 
net ist, um insbesondere eine günstige Datenträgserkonfiguration 
zu bestimmen. 

PL "OUTPUT TAFE REQUIRED ..." 

3? Start einer kagnetbanddruckausgabe: S$STPEi,adr 

53: "USER DISKS MUST BE RESERVED „.." 

4; - Überprüfung und ggf. Veränderung der Magnetplattenkonfigure- 
tion nittels der Informationen aus der Bedienerinformations- 
liste und Bedienerdisplaykommandos. Die für die bedienungsun- 
abhängige Betriebsweise vorgesehenen Nagnetplatten müssen den 
Status „reserviert" haben. 

- Fertigneldung durch $TS,FREE, 
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Sy: - Mitteilung Über verfügbare Magnetplatten; 
- "nn SYSTEM READY „.. REPLY Y OR N" 

Bo: - Antwort N veranlaßt eine Unterbrechung‘ des Umschaltprozesses, 
in der der Bediener ggf. noch Änderungen der Datenträgerkon- 
figuration vornehmen kann, insbesondere private Magnetbänder 
durch MOUNT-Kommando montieren kann und bedingt bedienungsun- 
abhängige Jobs in den Zustand bedienungsunabhängig versetzen 
kann, E 

- Antwort Y veranlaßt die Beendigung des Umschaltprozesses 
durch das System, 

Sz: Aktivierung des Konsolinterface und der Jobauswahl. 
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3. Bemerkungen zum Nutzen _des_ Systems 


Der duroh den Einsatz des Systems SPOOL 2,0 zu erreichende Nutzen 
liegt auf mehreren Ebenen und ist van verschiedenen Faktoren abhän- 
gig. Allgemeine Betrachtungen zum Nutzen des ‘Systems SPOOL sind /1/ 
zu entnehmen; Hier herausgegriffen seien nur die Effekte, die durch 
die oben dargestellten Komponenten des Systems erreicht werden, 


Generell känn der Effektivitätsgewinn und die Bedienerfreundlichkeit 
durch den allgemeinen Einsatz der magnetplattenabhängigen Jobauswahl 
genannt werden. Dem Bediener ist es mittels der ihm durch das Systen 
gegebenen ‘umfangreichen und detaillierten Informationsmöglichkeiten 
leicht möglich, effektive Datenträgerkonfigurationen zu geeigneten 
Zeitpunkten zu bestimmen; Wartezeiten durch nicht vorkergesehere 
bzw. Ausfallzeiten durch nicht erfüllbare Montieranforderungen 
(MP) entfallen. 


Ein weiterer ebenfalls insbesondere den Anlagendurchsatz positiv 
beeinflüussender Faktor ist die besonders effektive, da von jeder 
Kommunikation und Bedienerhandiung sowie von der Aktivität langsamer 
E/A-Geräte befreite Arbeit der EDVA während der bedienungsunabhän- 
gigen Betriebsweise. 


Die Erhöhung der Arbeitsproduktivität durch eine Konzentration der 
Bedienhandlungen auf bestinmte Zeiträume und das mögliche Betreiben 
der EDVA mit vermindertem Bedienpersonal im bedienungsunabhängigen 
Betrieb wurde schon einleitend erwähnt, Der hierdurch erzielte Nut- 
‚zen wird vom Umfang des Einsatzes der bedienungsunabhängigen Be- 
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triebsweise bestimmt. 


Die tägliche Dauer der bedienungsunabhängigen Zeitintervalle ist 
von verschiedenen Faktoren, wie Jobprofil, Gerätekonfiguration (MP, 
MB), Verteilung der Magnetplattendateien u.a. abhängig. Sie beträgt 
em Organisations- und Rechenzentrum der Humboldt-Universität durch- 
schnittlich 3-4 Stunden, wobei Spitzenwerte insbesondere an den 
Wochenenden von 7-10 Stunden erreicht werden. Diese Werte sind hier 
ermeiterungsfähig, da der Anteil der bedienungsunabhängigen Jobs 
durchschnittlich über 60 % beträgt. Bezüglich der Joblaufzeiten ist 
der Anteil der bedienungsunabhängigen Jobs noch größer. Die bedie- 
nungsunabhängige Betriebsweise wird dabei durch einen entsprechen- 
den Schichtplan unterstützt und wird verwendet, um die EDVA zu be- 
stimmten Produktionszeiten mit stark verringertem Bedienpersonal 

zu betreiben. Den Bedienpersonal kommt dabei lediglich die Auf- 
sichtspflicht und der Eingriff bei Havarien zu. Betont werden soll 
en dieser Stelle. daß das System SPOOL 2.0 in seiner bedienungsun- 
abhängigen Betriebsweise systemseitig die Produktion auch ohne Be- 
dieneranwesenheit sichern kann. 


Literaturhinweise 


/1/ Winks, Hans 
"SPOOL - "ein System zur Automatisierung von Produktions- 
prozessen an ESER-Rechnern!! 
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Meißler, "Hans-Günter 


SPOOLRJE - eine Fernverarbeitungskomponente des SPDOL-Systens 


1. Einleitung 


Aufbauend auf die Prinzipien des Arbeitsvorbereitungssystens 
SPOOL wird mit SPOOLRJE eine Möglichkeit der Jobfernverarbei- 
tung an ESER-Anlagen realisiert, 


Folgende Aspekte-sollen dabei berücksichtigt werden: 


- Die Vorteile der Stapelverarbeitung bleiben für den Betreiber 
der EDVA 'erhalten. 
Die Jobeingabe von entfernt aufgestellten Terminals an einen 
Zentralrechner, ihre Verarbeitung dort und die wahlweise Aug- 
gabe der Ergebnisse der Jobs am Terminal oder am Zentralrech- 
ner gestatten weiterhin die Vergabe von Prioritäten und Res- 
sourcen nach langjährigen und bewährten Verfahren, die eine 
bestmögliche Auslastung der EDVA sichern sollen, 
Das Rechenzeitregime, der Bediener oder entsprechende Über- 
wachungsprogramme des Zentralrechnerse bestimmen den Zeitpunkt 
der Jobannahme, Abarbeitung und Ausgabe. Das dem Betriebs- 
system beigeoränete Arbeitsvorbereitungssystem SPOOL unter- 
stützt diese, die ursprüngliche Arbeitsvorbereitung überge- 
hende, Arbeitsweise der. Jobeingabe durch die Angabe von vielen 
Jobparametern, die die Ressourcenbelastung des Jobs ausweisen, 


- Dem Nutzer des Zentralrechners bieten sich erweiterte Möglich- 
keiten. u 
‘Durch die Verwendung von Terminals, die am Arbeitsplatz des 
Nutzers oder in seiner unmittelbaren Nähe aufgestellt werden, 
verringern sich die Zeiten von der Formulierung des Problems 
über die Kodierung bis zur Eingabe in die EDYA beträchtlich, 
Es entfallen Wegezeiten, die Inanspruchnahme von. Datenerfas- 
sungsleistungen und die noch übliche manuelle Kontrolle auf 
Verwendungsdauer und Art der im Job benötigten Ressourcen, 
Im Gegensatz zu. Dialogsystemen, die in begrenztem Umfang auck 
eine Jobfernyerarbeitung gestatten, muß der Nutzer keine neue 
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Sprache zur Jabeingabe erlernen. Es genügt die ihm bisher 
bekannte Jobsteuersprache des OS/ES. Viele bekannte Aufge- 
benstellungen des Nutzers erfordern keinen direkten Dialog 
mit dem Zentralrechner; sie fallen in die auch stapelmäßig 
abarbeitbare Kategorie der Abfragen. 

Bestimmte Terminals gestatten dem Nutzer nach Absenden der 
Jobs kleinere Probleme offline, d. h. getrennt vom Zentral- 
rechner zu lösen. 

Wahlweise kann der Nutzer nur durch die Eingabe bestimmter 
Kommandos über TSO oder über SPOOLRJE mit dem Zentralrechner 
verbunden sein. 


2. Terminals und Leitungen 


SPOOLRJE unterstützt in verschiedenen Ausbaustufen unterschied- 
liche Terminaliypen. 

Eine erste Ausbkaustufe orientiert vorrangig auf reine Dialog- 
terminals, z. B. Typen wie AP64 oder BS7920. Hierbei ist nicht 
der spezielle Terminaltyp, sondern seine Nichtprogrammierbar- 
keit entscheidend für die Einordnung in diese Gruppe. Als Lei- 
tungen sollen vorrangig Standleitungen mit asynchroner oder 
synchroner Übertragung und Übertragungsgeschwindigkeiten bie 

zu 1200 Bd verwendet werden. Ein Übergang zu Wählleitungen ist 
geplant und soll zuerst am Datenhandvermittlungsnetz und im 
Telexnetz der Deutschen Post funktionell erprobt werden. Dazu 
werden auch Fernschreiber an Wählleitungen in dieser Ausbaustu- 
fe in SPOOLRJE mit einbezogen. Die praktische Verwendung dieser 
Terminaltypen zur Jobfernverarbeitung ist vor allem durch die 
niedrigen Übertragungsraten begrenzt. 

Eine weitere Ausbaustufe soll intelligente Terminals über 
SPOOLRJE an ESER-Anlagen koppeln. Sie arbeiten vorrangig mit 
synchroner Übertragung. Verschiedene Eingabegeräte der Terminals 
gestatten dem Nutzer breite Anwendungsmöglichkeiten, wie 2. B. 
die Eingabe vorgefertigter Jobs von Magnetkassette, Floppy Disk 
oder Lochstreifen, Korrektur, Ergänzung bzw. Überschreiben von 
Jobparametern am Bildschirm, Nach dem Absenden der Jobs kann 
der Nutzer das Terminal zur Lösung eigener Probleme verwenden, 
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Die-Art der am-Terminal-angeschlossenen ‚Ausgabegeräte be- 
stimmt::die Ausgabemöglichkeiten der Jobergebnisse, z. B. auf 
dem Bildschirm, Drucker oder Kassette. Die Entscheidung über 
das Ziel trifft der Nutzer am Terminal oder es werden Stan- 
dardannahmen vom Zentralrechner wirksam, die eine Ausgabe 

der Ergebnislisten auf eingeschaltete Hardcopy-Geräte vorneh- 
mens. 

Weitere Terminals dieser Ausbaustufe werden fernaufgestellte 
Kleinrechner sein, die über Lochkarteneingabegeräte, schnelle 
Drucker und große externe Speichermedien verfügen. Vorgesehen 
ist die Einbeziehung von SKR-Rechnern und von kleineren ESER- 
Anlagen. Die Effektivität der Fernverarbeitung wird dann zum 
großen Teil durch die Übertragungsgeschwindigkeit bestimmt, 

d. h.. es müssen Leitungen mit Übertragungsgeschwindigkeiten 
großer 2400 Bd verwendet werden. Die Übertragung erfolgt syn- 
chron mit speziellen Übertragungsprozeduren, die unter anderem 
eine Dätenreduktion gestatten. Der Zentralrechner bedient meh- 
rere Ein- und Ausgabegeräte der Terminals gleichzeitig. Über 
die Konsolen der Terminals und des Zentralrechners kann eine 
Bedienerverständigung erfolgen. 


3. Programmtechnische Lösung 


Die mit SPOOLRJE angestrebte Fernverarbeitungsvariante des 
SPOOL-Systems erfordert Software-Entwicklungen auf dem Zentral-. 
rechner (im SPOOL-S,stem und im Nachrichtenkontrollprogramn), 
dem Verbindungsrechner (i. a. Multiplexor auf der Basis KRS 
4201) und in den verschiedenen Terminalrechner (vorerst Mi- 
krorechner auf der Basis K1510/20 bzw. R21). 


3.1. Ergänzungen im SPOOL-System 


Die Eröffnung der Leitungen erfolgt in der Initialisierungs- 
phase des Systems oder auf Kommando des Bedieners. In einen 
eynchron von SPOOL-Dispatcher mit Zentraleinheitszeit versorg- 
tem Prozessor werden zyklisch alle eröffneten Leitungen auf 
einen Eingabewunsch der. Terminale überwacht. Liegt an einer 
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Standleitung ein Eingabewunsch vor, analysiert der Prozessor 
die Terminal- und Nutzeridentifikationsanweisung. Der Nutzer 
kann eine Verbindung mit dem Zentralrechner über TSO oder 

über SPOOLRJE wünschen, Ist das TSO nicht aktiv, werden 

Nutzer und Bediener davon informiert, wenn vom Terminal ein 
TSO-Kommando abgeschickt wurde. Soll die Eingabe über SPOOLRJE 
erfolgen, wird vom RJE-Prozessor, falls erforderlich, das ent- 
sprechende Nachrichtenkontrollprogramm (MCP) gestartet, das 
auf der Basis von TCAM die- Übertragung vom Terminal zum Zen- 
tralrechner übernimmt. Das MCP wird als asynchrone Task vom 
RJE-Prozessor, falls es nicht schon für andere Leitungen akti- 
viert war, gestartet. Das SPOOL-Systenm stellt somit für das 
MCP ein Anwendungsprogramm dar. Die vom MCP übernommenen Daten 
wer"sn in einer. Plattenwarteschlange zwischengespeichert und 
a.ıschließenc auf den als Internen Reader bezeichneten Eingang 
des SPOOL-Systeus in die SPOOL-QUEUE überführt. Damit erhält 
SPOOL die Möglichkeit der Kontrolle und Analyse der eingegebe- 
nen Jobsteue'‘ - und SPOOL-Steuerkarten. Nachdem SPOOL anhand 
einer speziellen Steuerkarte das Ende des dobstromes bzw. der 
Übertragung erkannt hat, wird über ein intern abgesetztes Kom- 
mando die Übertragung auf der benutzten Leitung gestoppt. 
Falls keine anderen Übertragungen im MCP mehr stattfinden, wird 
auch "das- MCP gestoppt. Bei Wählleitungen erfolgt zusätzlich 
noch ein. Kennungsaustausch und eine Kontrolle der Zuschaltbe- 
rechtigung des Terminals. Die eigentliche Übertragung erfolgt 
wie bei Standleitungen. 

Die in-die. SPOOL-QUEUE von entfernt aufgestellten Terminals 
delegierten Jobs erzeugen eine Bedienerinformationsliste wie 
andere von entsprechenden SPOOL-Geräten eingegebene Jobs. An- 
hand dieser Informationen steuert der Bediener oder das System 
die Auswahl der abarbeitungsfähigen Jobs. Nach der Abarbeitung 
stehen die Speziell gekennzeichneten Jobs der Fernterminals 
zur Ausgabe zur Verfügung. Anhand der ‘dem Job beigefügten In- 
formationen wird die Ausgabe am Zentralrechner oder am Temi- 
nal aktiviert. 

Die Aufteilung der Ergebnisse auf die möglichen Ausgabegeräte 
des Terminals erfolgt durch den Nutzer bei Jobeingabe, indem 
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er spezielle. Ausgabeklassen pder Geräte dafür vorsieht. Die- 
se Ausgabeklassen oder Geräte beziehen sich nur auf ein be- 
stimmtes Terminal, d. h. sie werden vom SPOOL-System nicht 
beachtet, Die Zuordnung zu physischen Geräten erfolgt durch 
das im Terminal aktivierte Programm (RTP) zur Zeit der Da- 
tenübernahme, Sollen die Ausgabedaten zum Terminal übertra- 
gen werden, versucht SPOOL nach Bestimmung des Terminals 
und der zugehörigen Leitung, diese zu eröffnen, Dabei muß 
die Empfangsbereitschaft des Terminals für mindestens ein 
Ausgabegerät vorliegen, Die eigentliche Übertragung über- 
nimmt wieder die vom RJE-Prozessor gestartete MCP-Task, die 
nach {ibertragungsende gutpmatisch gestoppt wird, wenn keine 
weiteren Übertragungen vorliegen. Sollte es nicht möglich 
sein, die Leitung zu eröffnen oder das Terminal ist nicht be- 
reit, so erfolgt nach einigen Versuchen eine. Nachricht an 
gen Bediener des Zentralrechners, der dann über die weiterg 
Verfahrensweise entscheidet, 

Auf diese Weise werden sowohl Stand- als auch wählleitungen 
nieht für die gesamte Sitz-ungsdauer, sondern nur für die 
eigentliche Übertragung mit dem Rechner verbunden. Dadurch 
wird u. a. die Kapazität der wenigen vorhandenen Wählleitun- 
gen effektiver genutzt. 

Spezielle Techniken der Datenreduktion erhöhen bei Synchron- 
übertragung die Datenübertragungsrate und die Ühertragungs- 
sicherheit, 


3.2. Änderungen im Emulaterprogramm 


Ausgehend von programmierbaren Multiplexoren machen sich Än- 
derungen an den gebräuchlichen Emulatorprogrammen erforder- 
lich. Die Emulatorprogramme müssen anhand spezieller Komman- 
docodes unterscheiden können, oh das ankammende Kommando vom 
SPOOL-System oder von einer anderen Zugriffsmethode ausging. 
Für Anforderungen yon SPOOL spll das Emulatorprogramm die 
Kontrplle der Leitungen übernehmen und über eine Statusände- 
rung des Subkanals dem RIE-Prozessor den Eingabewunsch des 
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Terminals signalisieren. Ist dagegen das MCP aktiv, so 
übernimmt dieses wie bisher üblich die Kontrolle der Leitun- 
gen. Für’ Wählleitungen 'muß das Emulatorprogramm so lange 
"Rechner besetät" melden, bis es vom RJE-Prozessor eine In- 
formation über die Aktivierung des MCP erhalten hat. Die De- 
legierung der Leitungsüberwachung für die Zeit zwischen den 
Übertragungen an das Emulatorprogramm trägt wesentlich zur 
Entlastung des Multiplexkanals des Zentralrechners bei. 


3.3. Anforderungen an das Remote Terminal Programm (RTP) 


Spezielle Anforderungen an das RTP hängen’sehr vom Typ und 

der Ausrüstung dJes Terminals ab. Einige grundlegende Forde- 
rungen müssen jedoch von jedem RTP erfüllt werden: 

Die Eingabe der Jobs kann von verschiedenen Geräten erfolgen, 
wobei tempor! re Modifikationen möglich sein sollen. Dabei muß 
sich das Terminal und der Nutzer durch spezielle Steuerkarten 
identifizier :n (LOGON für TSO-Betrieb, TCAMON für RJE-Betrieb). 
Der Abschluß. jedes Jobs und der gesamten Übertragung wird 

durch EOJ- bzw. EOF-Karten signalisiert. Terminals ohne Konso- 
len können über MESSAGE-Karten dem Bediener des Zentralrechners 
gewisse Informationen zukommen lassen. Informationen vom Bedie- 
ner des Zenwralrechnere können dagegen in der Eingabephase 
nicht empfangen werden. Die Eingabedaten werden wenn möglich 
verdichtet übertragen. Ein Offline-Betrieb des Teminals ist 
nach Absenden der EOF-Karte möglich. Dabei muß jedoch von je- 
dem offline-Programm eine primitive Leitungsüberwachung gesi- 
chert sein. Ist dies nicht möglich, so sind spezielle Zeiten 
zum Empfang der Daten über die Terminalidentifikation mit, dem 
Zentralrechner zu vereinbaren. Zum Empfang der Jobausgaben muß 
der Nutzer gegebenenfalls die offline-Verarbeitung unterbrechen 
und den 'Enpfangsteil des RTP aktivieren, 


3.4. Auswahl des Nachrichtensteuerprogramms 


Das zur Übertragung benötigte Nachrichtensteuerprogramm soll 
für den TSO-Betrieb und für den Anschluß anderer Anwenderpro- 
gramme geeignet sein. Deshalb sollten alle Terminals umschalt- 
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bar generiert werden. Die hachrichtenbehandler müssen den 
T5S0-Betrieb und die RJE-Komponente des SPOOL-Systems bedie- 
nen. Die Warteschlangen werden für TSO im Hauptspeicher und 
für SPOOL auf Wechselplatten gehalten. Die Verteilung der 
Nachrichten vom SPOOL-System an die entsprechenden Terminals 
erfolgt über die der Nachricht vorangestellten Identifikation 
des Terminals, 


4. Hauptspeicher- und Direktzugriffsspeicherbedarf 


Im SPOOL-System erhöht sich der Speicherbedarf bei Generierung 
des RJE-Prozessors auf Grund der Overlay-Struktur nur um weni- 
ge K-Byte. Während der Übertragung werden zusätzlich rund 
100k Byte für das MCP benötigt, die nach dem Stöppen wieder 
freigegeben werden. Zusätzlicher Direktzugriffsspeicher wird 
nur für die Plattenwarteschlangen des MCP benötigt, die aber 
relativ klein gehalten werden können, da die Nachrichten bei 
Freiwerden eines Internen Readers sofort an das SPOOL-System 
übergeben werden. 


5e Realisierungsstand 


Die erste Ausbaustufe, die nur dialogorientierte Terminals, 
Fernschreiter an Wählleitungen und keine Veränderung am Emu- 
latorprogramm beinhaltet, soll Mitte 1983 fertig sein. Die 
zweite Ausbaustufe ist vorerst für Terminals auf Mikrorech- 
nerbasis (K1510) und für die Kopplung eines R2i1 an den Zen- 
tralrechner vorgesehen, 


Verfasser: Dipl.-Math. Hans-Günter Meißler 
Martin-Luther-Universität 
Halle-Wittenberg 
4020 Halle, Weinbergweg 17 
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Dipl.-Math. Conrad Piens, Humboldt-Universität 


Effektivitätsuntersuchungen für das System SPOOL’3 


1. Zielstellung des_Systems_SPOOL_3 


Das System SPOOL 3 soll aufbauend auf dem Arbeitsvorbereitungs- 
system SPOOL 2.1 (s. /1/) den Produktionsprozeß an ESER-Rechnern, 
die mit dem Betriebssystem OS/ES betrieben werden, nach folgenden. 
Gesichtspunkten effektivieren: 


- rationelle Auslastung der Magnetdatenträger (sowohl Magnetplatten 
als auch Nagnetbänder); 

hohe Datensicherheit für den Nutzer (Entlastung des Nutzers von 
der Ve"antwortung für Sicherheitskopien seiner Dateien); 
"Minisnierung von Datenträgerwechseln (Magnetplatten); 

Beseitigung des Engpasses DA-Speicherplatz; 

Vergrößerung des Zeitraumes, in dem. das bedienungsunabhängige Be- 
treiben der EDV‘. möglich ist (vgl. /el). 


Un diese Zielstellung zu erreichen, wird mit SPOOL 3 ein Konzept 
eines virtuellen Direktzugriffsspeichers realisiert. 


Unter einem virtuellen Direktzugriffsspeicher wollen wir ein hier- 
aerchisch organisiertes Speichersystem für Dateien verstehen. Seine 
erste Hierarchiestufe umfaßt permanent montierte. Magnetplatten, 
den sogenannten POOL, die zweite Hierarchiestufe ein Magnetbandar-, 
chiv. Ein Datei- und Datenträgerverwaltungssystem sorgt dafür, daß 
sich alle Dateien, die von Jobs benötigt werden, zu deren Abarbei- 
tungszeit in der ersten Hierarchiestufe, also im POOL, befinden. 


SPOOL 3 soll neben Dateien, die sich im virtuellen Direktzugriffs- 
speicher befinden, auch Dateien auf privaten Magnetplatten und die 
übliche Arbeit mit Magnetbanddateien zulassen. 


Nach dem Einlesen der Jobs erfolgt die vollständige Kontrolle der 
Jobsteueranweisungen auf syntaktische Korrektheit. Gleichzeitig 
wird die zulässige Inanspruchnahme der von den Jobs benötigten Res- 
sourcen und die Verfügbarkeit der von ihnen benötigten Dateien im 
POOL geprüft, Falls nötig, werden Dateien aus der zweiten Stufe des 
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Speichersystems in die erste Stufe transportiert. Erst wenn alle 
von einem Job benötigten Dateien im POOL verfügbar sind, wird die- 
ser Job zur Bearbeitung freigegeben. Ist im POOL kein Platz für 
die einzulagernden Dateien, müssen momentan nicht benötigte Dateien 
in die zweite Stufe ausgelagert werden. 


Es ist offensichtlich, daß das Konzept des virtuellen Direktzu- 
griffsspeichers neben den gewünschten Effektivitätsgewinnen auch 
Belastungen für die Systemarbeit mit sich bringt. Diese Belastungen 
bestehen im wesentlichen in den Dateitransfers zwischen den Stufen 
des Speichersystems. Um also erste Aussagen über die Gesamteffekti- 
vität des Systems treffen zu können, ist die zu erwartende Häufig- 
keit von Dateitransfers zwischen den Stufen der Speicherhierarchie 
zu ermitteln. Weitere Untersuchungen beträfen z.B. die nötige Grüße 
und mögliche Ausdehnung des Magnetbandarchivs, die zu erwartenden 
Häufigkeiten von notwendigen Magnetbandmontagen zur Gewährleistung 
des Datentransfers, die Zeit, die zur Dateibereitstellung im POOL 
nötig ist und die zu erwartende Häufigkeit des Verdichtens der Ma- 
gnetbänder des Archivs. Möglich und notwendig sind auch Untersu- 
chungen zur optimalen Dateiverteilung auf den Magnetplatten des 
POOL'!s (vgl. /4/). 


In diesem Beitrag sollen lediglich Betrachtungen zur zu erwartenden 
Häufigkeit von Dateitransfers angestellt werden. 


3.1. Modell der Datei- und Datenträgerverwaltung 


Um Aussagen treffen zu können, wurde ein stark vereinfachtes Sinu- 
lationsmodell der Datei- und Datenträgerverwaltungskomponenten von 
SPOOL 3 geschaffen (s. /3/). In diesem Modell werden beide Stufen 
des Speichersystems als jeweils homogenes Speichermedium aufgefaßt, 
das heißt, der POOL wird durch eine Magnetplatte gewünschter Kapa- 
zität und das Magnetbandarchiv durch ein Magnetband beliebiger Ka- 
pazität repräsentiert. Alle Aktionen werden zeitlos, also ohne Be- 
rücksichtigung ihrer realen Dauer, ausgeführt. Von diesem Sinmula- 
tionszodell werden speziell aufbereitete SMPF-Sätze vom Typ 14 und 
15 (Sätze zur Erfassung der Dateiverarbeitung) verarbeitet und alle 
interessierenden Häufigkelten von Anforderungen an das Datei- und 
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Datenträgerverwaltungssystem ermittelt. Die Größe des POOL'!s und in 
gewissem Sinne auf die Auslagerungsstrategie können variiert werden. 


Bei jeder Dateianforderung wird ein Algorithmus gemäß Bild 1 abge- 
arbeitet. Dabei erfolgt die Auslagerung von Dateien nach einer mo- 
difizierten LRU-Strategie, wobei gesteuert werden kann, ob ledig- 
lich für die zu bereitstellende Datei Platz im POOL geschaffen oder 
der POOL bis auf eine vorgebbare Grenze geleert werden soll, 


I; Datei vr Fool! A i 


Batcıkranstfeor 
MB-Archir > Pool 


Bild 1 


Mittels des oben beschriebenen Modells wurden die von der Funktion 
„erfassen der Ressourcenbenutzung" bereitgestellten Dateiverarbei- 
tungssätze eines Zeitraumes von 61 Tagen verarbeitet. In diesem 
Zeitraum wurde von 3556 Jobs zu 444 Dateien, die der Datei- und Da- 
tenträgerverwaltung von SPOOL 3 unterliegen sollen, insgesamt 
19054 mal zugegriffen. Diese Dateien belegen einen Speicherplatz 
von 39248 Spuren auf WPS vom Typ 5061, das entspricht also einer 
Kapazität von ca. 290 M Byte. In den verschiedenen Simulationsläu- 
fen wurden die POOL-Kapazität und der bei Auslagerungen frei zu 
machende Speicherplatz variiert, um Zusammenhänge zwischen diesen 
Größen und den Dateitransfers zwischen POOL und Magmetbandarchiv 
ableiten zu können. Bei allen hier dargestellten Ergebnissen wird 
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sgegangen, daß sich zum Beginn des Simulationszeitraumes 
eien ausschließlich im MB-Archiv befinden. Andere Simula- 
fe haben ergeben, daß eine Vorbele,ung des POOL's nur un- 
chen Einfluß auf die Anzahl der nötigen Dateitransfers hut. 


abelle 1 bezeichnen 


FOOL-Kapazität in Spuren auf WPS 5061 

frei zu machenden Speicherplatz. in % der POOI.-Kapazität, 
f bedeutet, daß nur für die anliegenden Dateieinlagerun- 
gen Flatz geschaffen wird 

arithnmetisches Nittel der Anzahl von Jobs pro Tag, die 
Dateieinlagerungen erfordern 

arithnetisches Nittel der Tage, . die zwischen zwei notwen- 
digen Austiagerungen liegen 

Arteil der Jobs, die Dateieinlagerungen verlangen, in Pro- 
zent 


arithmetisches Mittel der Dateitransfers pro Tag 
arithmetisches Mittel: der Dateieinlagerungen pro Tag. 


.- 


= 


FP d.; pt DE PJ 

0 111,5 | 0,1 | 36,2 | 23,7 |. 21,1 

10 112,5 | 0,7 | 40,3 | 25,2 | 21,4 
20 12,8 1,2 44,9 «27,6 23,7 
30 | 14,4 | 1,6 | 47,1.| 29,5 | 24,8 
a0 15,2 1,9 49,7 31,0 26,0 
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n 5,204 | A254 10,8 a,i 

10 | 5,5744 | 1,0] 19e | 9,5 
N ie Te te 7 
| ae Se Hr 17 31 
el sales 1 nr 


1 


- 


1. Ausgangspunkt > 
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Weickmann, Christoph . i 

GCemeinsame*Nutzung von TSC und SPOOL zuf einer ENVA 

Das Teilnehmersystöm TSG bietet u. a. die Möglichkeit, Stanelic 


im Ninlog = zZ. B. mit Hilf :e des Kommandos FÜIT - zu erstellen ı 
zu aktualisieren und diese: so behandelten Jobs direkt in die R 
Jobkettendatei ‚des OS/IS zu delegieren, ‚Diese Art der Arbeit h 
den vorteil, daß rechnerintensive Aufgaben ‚nicht. den Dialog he- 
lasten, sondern 'parellel zu TS0O oder ‚anschließend sbgearheitet 
“werden. ‚Dies gilt Zz.R. für längere Üibersetzungsläufe, Johs der 
n,roduktionssteuerung- "oder. auch ‚Aufgaben des TSO-Nialogs’ für' das 
PP Statistik. ‚Der Teilnehrer nutzt dadurch TSO mehr für die 
Programmerstellung und “testung sovie für die Lösung von Aufoe- 


ben, die dialogorientiert aufgebaut 'sind. 


Diese Möglichkeit, den Vordergrund. (Dialogarbeit) mit dem Hlinte 
grund (Stapelarbeit) zu verbinden, wird Foreground- -Initiated- 
Background (FIB) genannt. Für FIB. gibt es eine Gruppe von 'Kon- 
mandos, für die der Teilnehner vom Rechenzentrum Privilegiert 


sein muß, Sie ‚ermöglichen:- ge 
- Delegieren. von Jobs; Be l: 

- Streichen von delegierten Jobs; 

= Ausgabe der Ergebnisse ‘von delegierten Jobs ' am Terminal; 


= Anzeige des Bearbeitungs Standes delegierter Yobs em ‚Terminal, 


„[s handelt sich, hierbei un die Kommandos SUMHIT., FARGEL „OUTRUT 
und STATUS, a Ü Eu 


r4 
Aufgaben ‚der. ‚Bonmändos BEN 


- SUSHIT.: A 
- Prüfen, ob der Teilnehner.. für "TR zugelässsen ist; 


- Hinzufügen einer IJobkarte, fells der Sobstron nicht-rit einer 


beginnt; 

- Hinzufügen eines Eeterscheidungszeichene, falls.der Jahnane n 
aus den !eilnehwerkennzei ichen les Ataht; 

- Höglichkeiten eines Ben it deäsen jife das 'Rachenzentrun 


\ ir 
technologische Vorgzben wie CPlI-Zeit, Regiensgröße, RLASS-Par 
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meter oder SYSOUT-Klassen automatisch prüfen oder ergänzen 
kann, bzw. durch den Job auch gestrichen werden können, wenn 
sie diese Vorgaben nicht enthalten; 

- Delegieren des Jobs in die Jobketrendatei des OS/ES. 

CANTE 

- Prüfen, ob der Teilnehmer für FIS zugelassen ist; 

- Prüfen, ob der Jobname mit dem Teilnehmerkennzeichen beginnt; 


- Streichen des Jobs ‘aus einer der Ketten der Jobkettendatei 
bzw. aus der Abarbeitung. 


OUTPUT: 

- Prüfen, ob der Teilnehmer für FIB zugelassen ist; 

- Prüfen, ob der Jobname mit dem Teilnehmerkennzeichen beginnt; 

- Ausgabe von SYSOUT-Dateien am Terminäl; 

- Um’ etten von SYSQUT-Dateien in Klassen, die vom Systemausgabe- 
3rogramm bedient werden; 

- Streichen n’cht benötigter SYSOUT-Dateien, 


STATUS: 
- Prüfen, ob ser Teilnehmer für FIB zugelassen ist; 
- Anzeige des Bearbeitungsstandes der Jobs am Terminal. 


Da das Preschedulingsystem SPOOL an Nechenzentren des Hochschul- 
wesens immer häufiger zum Einsatz kommt, ist es wichtig, die 

von TSO delegierten Jobs dem technologischen Regime von SPOOL 
anzupassen, Das heißt, daß diese Jobs auch durch die Tobäuswahl, 
die Druckaufbereitung, die Prüfungen zur Verfügbarkeit von 
Ressourcen usw. von SFOOL bedient werden. Andererseits würde 

es unnötige technologische Probleme geben, wenn bei paralleler 
Arbeit von TSO und’ SFPOOL Jobs sowohl direkt - mittels TSO-Komman- 
do - als auch über die Jobauswahl von SPOOL in die Jobkettendatei 
können, Gamit würden such alle techrologischen Vorteile verloren 
gehen, die in den Jobklassifizierungen, der Prüfung der Ressoöurcen- 
nutzung, der Möglichkeit des bedienungsunabhängigen Betriebes 

der Druckunterstützung usw. liegen. 


Auch um eine Vereinheitlichung in der Stapelarbeit zu erreichen, 
werden die nachfolgend beschriebenen.Änderungen an den FIR- 
Kommandos vorgenommen, 
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2. Aspekte der gemeinsamen Nutzung von TSO und SPOOL auf einer 
EDVA 


Bei der gemeinsamen Nutzung non TSO und SPOOL muß der zur Verfü- 
gung stehende Hauptspeicher berücksichtigt werden. Steht eine 
schnelle Anlage von ein MB, und mehr zur Verfügung, kann eine 
parallele Arbeit von TSO und SPOOL e ngeplant werden, Da es je- 
doch auch in Zukunft Anlagen mit 512 K Hauptspeicher geben wird 
und auf diesen TSO Bad SPOOL sinnvoll genutzt werden wird, muß 
die. Möglichkeit einer seriellen Arbeit von Dialog und Stapel be- 
rücksichtigt werden. 


Entsprechend diesen zwei Aspekten - parallele bzw. serielle Ar- 
beit von Dialog und Stapel - wird bei der Bearbeitung der Komnman- 
doprozessoren unterschieden in 


a) SPOOL ist im System und aktiv, 
b) SPOOL ist im System und nicht aktiv. 


3, Leistungen der geänderten Kommandoprozessoren 


a) SPOOL ist im System und aktiv 


Generell gilt für alle Kommandoprozessoren, daß die Leistungen 
- insbesondere die technologische Seite betreffend - voll erhal- 
ten bleiben. "u 


SUBMIT: 


Die Jobs werden in die SPOOL-Jobdatei (SPOÖLQUEUE) delegiert. 
Dafür wird das Interface des internen Readers von SPOOL benutzt. 


Um dieses Interface nutzen zu können, ist es erforderlich, 'um«- 
fangreiche Anpassungen an den Routinen zur dyriamischen Datei- 
zuweisung (DAIR) für die TSO-Arbeit: vorzunehmen, 


Die dynamische Dateizuweisung unter TSO ermöglicht es, daf sich 
der Teilnehmer während einer Sitzung Dateien nach Bedarf zuwei- 
sen oder freigeben kann, Dies wird unter TSO jedoch nur für De- 
teien unterstützt, die sich auf DA-Geräten befinden. Magnetband- 
geräte, Drucker, Lochkartenleser usw. werden nicht prinzipiell 
unterstützt, da hierbei vom Teilnehmer nicht nur eine Datei, son- 
dern ein ganzes Gerät blockiert würde, 


Um jedoch für SUBMIT das Interface des internen Readers von 
SPOOL zu nutzen, ist es notwendig, daß dem Teilnehmer ein SPOOL- 
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DUMMY=-Gerät dynamisch zugewiesen und von ihm später wieder frei- 
gegeben wird. 


CANCEL : 


Für die Ausführung dieses Kommandos werden die Möglichkeiten 

von SPOOL genutzt, indem die Steuerblöcke von SPOOI. durchsucht 
werden. Das Streichen eines gefundenen Jobs erfolgt dann mittels 
eines SPOOL-Kommandos. 


OUTPUT : 


Der Teilnehmer muß, wenn er sich SYSOUT-Dateien über das Terminal 
ansehen will, für seine zu delegierenden Jobs SYSNUT-Klascen 
wählen, die in der Jobkettendatei verbleiben. Für das Umketten 
von SYSOUT-Dateion werden Klassen vorgemerkt, die außerhalb von 
SPJOL ausgedruckt werden. 


STATUS: 


Informationer über den Bearbeitungsstand eines Jobs werden den 
Steuerblöcken von SPOOL entnommen. 


b) SPOOL ist im System und nicht aktiv 


Auch hierbei gilt, daß der Leistungsumfang der Kommandoprozessoren 
nach Möglichkeit erhalten bleibt. 


SUBHIT : 


Die Delegierung von Jobs erfolgt hier in eine urtergliederte 
Datei, Dabei wird als Bestandsname der Jobname gewählt. Exi- 
stiert ein Bestandsname schon, so wird ein neuer Jobname ange- 
fordert. Die Jobs aus dieser 'Datei rrerden beim SPOOL-Start in 
die SPOOL-Jobdatei übernommen,und nach erfolgreicher !ibernahme 
wird der bisher belegte Flatz freigegeben. 


CANCEL : 


Das Streichen von Jobs wird sich hierbei nur auf die unter- 
gliederte Datei beschränken, 
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OUTPUT : 


Für die Möglichkeiten von OUTPUT bei der seriellen Arbeit von 
Dialog und Stapel gilt das Gleiche wie bei der parallelen 
Arbeit, obwohl die Anwendung dieses Kommandos infolge der 
zeitlichen Verschiebung von Dialog-Stapel-Nisalog nicht sehr 
sinnvoll ist. 


Delegierte Jobs werden nur in der PO-Datei gesucht. 


4. Bearbeitung 


Die Änderungen an den Kommandoprozessoren erfolgen an eindeuti- 
gen Schnittstellen mit Hilfe von Rahmenprogrammen, so daß Än- 
derungen des Systementwicklers ohne weitere Probleme wirksan 
werden können. Nie vorhandenen Routinen der FIB-Kommandos werden 
weitestgehend genutzt. 


Verfasser: 


Dipl.-Math. Christoph VWeickmann 
Humboldt-Universität 

ORZ 

1686 Berlin, PSF 1297 
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wörfel, Friedhard 


Aufbau und Handhabung des Systems der Katalogdateien für 
SPOOL 


1 Einleitung 


Das SPOOL-System ist ein Pre- und Post-Schedulingsyätenm, das 
als ergänzende Komponente des Betriebssystens OS/ES für die 
Steuerprogrammkonfiguration MFT und MVT einsetzbar ist. SPOOL 
übernimmt in effektiver Form die Jobeingabe und -ausgabe, 

führt Prüfungen zur Zugriffsberechtigung zu Dateien bzw. Daten- 
trögern, sowie zur Verfügbarkeit der Ressourcen Rechnerlauf- 
zeit (Rechnerkosten), Druckerpapier und Speicherplatz auf Mag- 
netplatte aus. 


2. Das Syster der Katalogdateien 


® 
Die Katalogdateien des SPOOL-Systems stellen eine Gruppe mit- 
einander verketteter Dateien dar, die zur Zugriffsprüfung und 
zur Verbrauchserfassung von bestimmten Ressourcen dienen, die 
von den im SPOOL-System bearbeiteten Jobs benutzt werden. Fol- 
gende Katalogdateien sind im SPOOL-System vorhanden,, 


2.1. Auftragsnummerndatei 


Diese Datei ist ein Verzeichnis der im SPOOL-System registrier- 
ten Aufträge. Jeder Auftrag wird durch eine 8-stellige Auftrags- 
nummer gekennzeichnet. Zu jeder Auftragsnummer sind Informatio- 
nen über Beginn und Ende der Auftragsgültigkeit und über die 

von Auftrag kummultativ in Anspruch genommenen Größen des Pa- 
pierverbrauchs, des Direktzugriffsspeicherplatzes und der 
Rechnerkosten vorhanden. Für die Verbrauchsgrößen sind Limit- 
werte eingetragen, ‚die nicht überschritten werden dürfen. Zu 
jeder Auftragsnummer können beliebig viele 8-stellige Nutzer- 
kennzeichen vergeben werden. In diesem Fall werden auch die 
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Verbrauchsgrößen für die. einzelnen Nutzerkennzeichen erfaßt. 
Eine Limitierung der Verbrauchsgrößen ist nur für den gesam- 
ten Auftrag möglich. Die inhaltliche Bedeutung des Nutzer- 
kennzeichens bleibt dem jeweiligen Anwender des SPOOL-Systens 
überlassen. Auftragsnummer und Nutzerkennzeichen werden aus 
geeigneten Parametern der Jobanweisung entnommen. 


2.2. Dateiverzeichnis 


Dieses Verzeichnis enthält Informationen zu allen Dateien, die 
sich auf Direktzugriffsdatenträgern befinden und für eine. per- 
manente Nutzung durch unterschiedliche Jobs im SPOOL-System 
zugänglich sein sollen. Als Dateinamen sind im SPOOL-System 

nur einfache oder untergliederte Namen zugelassen. Zwei phy- 
sisch verschiedene Dateien dürfen nicht den gleichen Namen be- 
sitzen. Zu jedem Dateinamen muß ein autorisierter Auftrag durch 
seine Auftragsnummer angegeben werden. Als Zusatzinformation 
kann ein zugehöriges Nutzerkennzeichen eingetragen werden. Re- 
gistriert werden das Einrichtungsdatum, das Datum des letzten 
Zugriffs, die Zahl der Zugriffe, das Verfallsdatum und die Pri- 
märspeicherplatzmenge. Der Datenträger auf dem sich die Datei 
befindet, wird durch einen Verweis auf den Satz des Datenträger- 
verzeichnisses festgehalten. Alle Dateien auf dem gleichen Da- 
tenträger sind durch die entsprechenden Verweise auf die Sätze 
des Dateiverzeichnisses miteinander vorwärts und rückwärts ver- 
kettet. Das gleiche gilt für Dateien, die in der höchsten Index- 
stufe den gleichen Namen besitzen, 


2.3. Datenträgerverzeichnis 


Diese Datei enthält Angaben zu jedem Datenträger, der im SPOOL- 
System registriert ist. Zu jedem Datenträgernamen muß ein auto- 
risierter Auftrag durch seine Auftragsnummer angegeben sein, 
Als Zusatzinformation kann ein zugehöriges Nutzerkennzeichen 
eingetragen werden. Außerdem werden eine Eigentümeridentifika- 
tion und der Gerätetypcode eingetragen. Bei Direktzugriffsda- 
tenträgemn wird ferner die Anzahl der (im Rahmen des SPOOL- 
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Systems) angelegten Dateien und zwei Verweise in das Dateiver- 
zeichnis auf den Anfang und das Ende der Kette der Dateien die- 
ses Datenträgers abgespeichert. Alle Datenträger, deren Namen 

mit der gleichen 3-stelligen Zeichenkette beginnen, werden durch 
Verweise auf die entsprechenden Sätze des Datenträgerverzeichnis- 
ses vorwärts und- rückwärts verkettet.. 


2.4, Zentraler Katalog 


Der zentrale Katalog. ist eine nach den Auftragsnummern geglieder- 
te Hilfsdatei. Sie ermöglicht. einen einfachen und schnellen Zu- 
griff zu den bereits genannten Verzeichnissen. Es sind Informa- 
tionen abgespeichert, die die Verfügbarkeit der einzelnen Auf- 
träge über Dateien und Datenträger regeln. 


2.5. Rückpointerlatei 


Diese Datei is, eine weitere Hilfsdatei. Sie hat die Aufgabe, 
eine Rückverkettung vom Dateiverzeichnis und Datenträgerverzeich- 
nis zu allen ‘Aufträgen zu ermöglichen, die eine Verfügbarkeit 
über eine bestimmte Datei oder einen bestimmten Datenträger be- 
sitzen. Es wird nur die Verfügbarkeit aller nichtautorisierten 
Aufträge geregelt. Alle autorisierten Aufträge sind direkt über 
den Zentralen Katalog mit ihren zugeordneten Dateien oder Daten- 
trägern verkettet. 
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2.6. Schema der Verkettung 


ACC 


[6] 4) (5) 


Erläuterungen: 
°’KAT - Zentraler Katalog 

ACC - Auftragsnummerndatei 

DSV - Dateiverzeichnis 

VOL - Datenträgerverzeichnis 

UT1 - Rückpointerdatei 

(1 ) = Vermeis auf einen Satz 

(2) - Auftragsnumner 

(3 ) - Verweis auf einen Satz 

(4 ) - Autorisierte Auftragsnummer 
(5 ) - Auftragsnummer 

(6.) - Autorisierte Auftragsnummer 
(7 ) - Verweis auf einen Satz 

(8 ) - Verweis auf einen Satz 


w 


(€) 
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(9 ) - Verweis auf einen Satz 
(10) - Verweis auf zwei Sätze 
(11) - Verweis auf einen Satz 


3. Der interne Aufbau der Katalogdateien 


Alle Katalogdateien des SPOOL-Systems sind nach einem einheit- 
lichen Prinzip aufgebaut. Außer dem zentralen Katalog, der eine 
untergliederte Datei ist, sind alle anderen Dateien sequentiell 
organisiert. Sämtliche Dateien enthalten ungeblockte Sätze 
fester Länge. Der gesamte Datenbereich der Dateien ist formati- 
siert und die Sätze sind in mehrfacher Weise untereinander ver- 
kette. Die freien Sätze jeder Datei bilden die sogenannte 
Freibereichskette. Durch Ein- und Ausketten von Sätzen der 
Freibereichskette ist es möglich, den freien Bereich der Dateien 
wartungsfrei zu verwalten. Eine Reorganisation der Dateien ist 
nur dann erforlerlich, wenn nicht mehr genügend freie Sätze vor- 
handen sind. 


Zur Verkettung der Sätze werden die relativen Spur- und Satz- 
adressen in den jeweiligen Dateien benutzt. Diese sogenannten 
TTR-Pointer werden immer in einem an Wortgrenze ausgerichteten: 
Bereich von vier Byte Länge eingetragen. Die rechten drei Byte 
enthalten die relative Spur- und Satzadresse des Satzes, auf den 
verwiesen wird. Im linken Byte ist das Bit ® für eine Anzeige- 
funktion reserviert. Die Bits 1 - 7 können für spezielle-Kenn- 
zeichnungen verwendet werden. Das erste Wort der Sätze aller 
Katalogdateien enthält stets einen TIR Pointer, durch den pri- 
mär zusammengehörende Sätze einer Datei verkettet sind. Im lin- 
ken Byte dieses Wortes wird in den Bits 1 - 3 die Art des 
Satzes und in den Bits 4 - 7 die Anzahl der Eintragungen im 
Satz angezeigt. 


4. Das Katalogdatei-Dienstprogramm IEBSPOOL 


Aufgabe des Programms IEBSPOOL ist es, das Eintragen, Ändern 
oder Entfernen von Informationen in bestehenden Xatalogdateien 
auszuführen. Die einzelnen Funktionen werden im allgemeinen 
über Steueranweisungen angefordert. Das Aufnehmen und Entfer- 
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nen von Dateien erfolgt automatisch, wenn dem Jobschritt für 
IEBSPOOL entsprechende DD-Anweisungen beigefügt werden, 

Einem bestimmten Job ist der Zugriff und die Veränderung nur 
an solchen Informationen der Katalogdateien gestattet, für die 
er durch seine Auftragsnummer autorisiert ist. Ausgenommen von 
dieser Regel sind sogenannte privilegierte Jobs. Privilegierte 
Jobs können jede beliebige Änderung am System der Katalogda- 
teien vornehmen. 


4.1. Aufbau derSteueranweisungen für IEBSPOOL 
/ 


Die Steueranweisungen besitzen Lochkartenformat. In Spalte 1 
steht das Kartenkennzeichen\y, der Anweisungstext steht in 
den Spalten 2 - 71. Die Spalten 72 - 89 sind bedeutungslos. 
Der Anweisungstext hat folgenden Aufbau 


X [Name] OPERATIONSCODE OPERANDEN [Kommentar] 


Die einzelnen Felder werden durch mindestens ein Leerzeichen 
voneinander getrennt. Das Operandenfeld besteht aus einem 
Stellungsoperanden und aus verschiedenen Kennwortoperanden. 
Eine Fortsetzung des Operandenfeldes auf Folgekarten ist mög- 
-lich und wird durch ein Komma mit einem darauffolgenden Leer- 
zeichen angezeigt. Auf der Fortsetzungskarte muß in Spalte 1 
das Kartenkennzeichen stehen. 


4.2. Operationscode 


Durch den Operationscode wird im allgemeinen eine Gruppe von 
Funktionen des Programms ausgewählt. Die genaue Funktion wird 
erst durch die Angabe bestimmter Kennwortoperanden festgelegt. 
Es gibt folgende Operationscode: 


PARM - Steuern des Programmlaufes 
OPEN - Hinzufügen eines neuen Auftrages 
CLOSE - Stormnieren eines Auftrages 
PURGE - Entfemen eines Auftrages 


ADD - Hinzufügen von Informationen in die Dateien 
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CHANGE - Ändern von Informationen in den Dateien 
DELETE - Entfernen von Informationen aus den Dateien 
CONNECT - ‚Herstellen einer Beziehung zwischen Objekten 
RELEASE - Aufheben einer Beziehung zwischen Objekten 
RENAME - Umbenennen von Objekten 


4.3. Stellungsoperand 


Alle Steueranweisungen besitzen einen Stellungsoperanden, des- 
sen Wert stets die Nummer eines autorisierten Auftrages dar- 
stellt. 


4.4. Kennwortoperanden 


In den Steueranweisungen kommen 21 verschiedene Kennwortoperan- 
den vor. Die gewünschte Programnmfunktion wird jeweils durch 
eine Kombination eines Operationscodes mit bestimmten Kennwort- 
operanden ausgewählt. 


5. Das Initialisierungsprogramm SPLINIT 


Aufgabe des Programms SPLINIT ist es, das Initialisieren der 
SPOOL Katalogdateien vorzunehmen, Dazu wird der gesante Pri- 
märdatenbereich der entsprechenden Dateien im OUTPUT-Modus 
formatisiert. Bei der untergliederten Datei wird außerdem das 
Verzeichnis geleert. Alle Datensätze werden als frei gekenn- 
zeichnet und miteinander verkettet, 


6. Das Korrekturprogramm SPLFILL 
Aufgabe des Programms SPLFILL ist: 


- füllen der initialisierten Katalogdateien mit Testdaten, 

- korrigieren von Satzteilen in hexadezimaler und in Zeichen- 
kettenform, 

- erzeugen von Bestandseintragungen im Zentralen Katalog, 

- korrigieren des Nutzerdatenfeldes von BeSstandseintragungen 
im Zentralen Katalog. 
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7. Das Druckprogramm SPLLIST 


Aufgabe des Druckprogramms SPLLIST ist das Auflisten von ob- 
Jektbezogenen Informationen und das Auflisten von dateibezo- 
genen Informationen, 


8. Das Wiederherstellungsprogramm SPLREST 


’ 


Aufgabe des Programms SPLREST ist das Wiederherstellen aller 
Dateien im Fehlerfall mittels Sicherungsabzug und LOG-Datei. 


9. Das Reorganisationsprogramm SPLCOPY 


K7 


Aufgabe des Programms SPLCOPY ist die Erweiterung der Frei- 
bereichskette einzelner Dateien und die Reorganisation aller 
Dateien, 
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Anke, Hartmut 


Erfahrungen nit einem System zur Jobverwaltung 


1. Einleitung ) 


In Eael nechanzirtein mit massenhaftem Anfall von Aufträgen 
ist die Jobverwaltung ein permanentes Problem. Die Tagerung, 
das Wiederauffinden oder der Tranport von Lochkarten inner- 
halb und außerhalb des RZ, die Zuordnung von Ausgangs- und 
Ergebnisdaten, all das sind Prozesse mit hohem manuellen Auf- 
wand und sich stündig wiederholenden Routinehandlungen. Dar= 
überhinaus sind die Jobdurchlaufstrategien selbst vor allem 
durch ihre man ıelle Realisierung geprägt. Hier spielen weni- 
ger volkswirtsc.aaftliche Aspekte eine Rolle, als vielmehr 
ihre Wachbark it bezüglich des Aufwandes. 

Ausgehend von der Verpflichtung durch Forschungs- und Ent- 
wicklungsarbeiten ökonomische Effektivität zu gewinnen, ve 
sucht das nachfolgend beschriebene Programmsysten einige 
Probleme zu lösen bzw. deren Lösung zu unterstützen. Hierbei 
seht es um die Einsparung lebendiger Arbeit, die Intensivie- 
rung aller Prozesse vor allem durch Erhöhung des Automatisa- 
tionsgrades und die intensive Ausnutzung der vorhandenen 
Technik,aber auch um die Nutzung des vorhandenen wissenschaft- 
lichen Potentials, vorhandene Erkenntnisse praxiswirksam zu. 
machen. 

Geleitet von dieser zrundsätzlichen Einstellung wurde in 
Rechenzentrum der Technischen Universität Dresden ein Pre= 
schedulinssystem entwickelt, implementiert und in der Pro- 
duktion erprobt, das Auftragswarteschlangen verwaltet. Wir 
bezeichnen dieses Programnsysten als Job-Queue=-kanagenment- 
Systen (JQMS). 
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2. Entwicklungsziele 


Das JQUS ist grundsätzlich zur Unterstützung eines stapelver- 
arbeitenden Betriebssystems gedacht. Das entspricht auch cer 
vorherrschenden Betriebsweise des Rechnersystems BES116/5S1020 
am RZ der TUD, welches sich als möglicher erster Einsatzfall 
anbietet. 

Folgende allgemeingültige EntwicklungsZiele wurden festgelest: 


- Unterstützung eines prioritätsgesteuerten Jobdurchlaufs 


Unter Jobdurchlauf verstehen wir die Gesamtheit aller Pro- 
zesse im Rechenzentrum, die die Verweilzeit einer Aufgabe 
beeinflussen, beginnend bei der Jobabgabe und endend mit der 
Rückgabe der Ergebnisse. Als dominierende Einflußgröße soll 
dabei die Dringlichkeit der Aufgabe wirken. 


- Bereitstellung effektiver Zugriffsmöglichkeiten zu Job- 
warteschlangen 


In diesem Zusammenhang verstehen wir unter Effektivität die 
Tatsache, daß der Maschinenbediener aus einer aktuellen Si- 
tuation im Produktionsbetrieb heraus — einfach, schnell, fle- 
xibel - ganze Jobstapel erzeugen kann, die er zur Abarbeitung 
benötigt. Dabei soll ihm ein bestimmter —- aber besonders im 
Verhältnis zur Priorität der Dringlichkeit wohldefinierter - 
Freiraum zur Verfügung stehen. 


- Unterstützung des rationellen Umgangs mit Rechnerressourcen 


Unter der Voraussetzung einer Ressourcenzuteilung können eine 
laufende, automatische Kontrolle und daraus abgeleitete Naß- 
nalyen zur Steuerung des Nutzerverhaltens beitragen. Die Über- 
wachunz bezieht sich dabei sowohl auf den Ressourcenverbrauch 
selbst, als auch auf die zeitliche_Inanspruchnahne. 


- Unterstützung für Leitungs- unä Planunssprozesse in Rechen- 
zentrun 


Dazu sollen »vorrangig objektive Daten zur Verfügung gestellt 
werden, die bei der Beurteilung von Prozessen oder Technolo-= 
gien mehr und mehr die subjektiven Einschätzungen durch ob- 
jektiv Begründete Faktoren ersetzen. Die Transparenz des Ge=- 
samntablaufes soll durch geeignet verfügbare Meßdaten erhöht 
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werden, Die Planung des- durchgehenden. Schichtbetriebes sowie 
die Erarbeitung von Prioritätsstrategien soll unterstützt 
werden. 


3. Systemarchitcektur 


Die 0.g. Zielstelluns und das Bestreben, die Abbildung des 
unterstützten Betricbssystems strenz von den allrzeneinztilti- 
zen Alsorithmen zu trennen, führten zu einem 2-Schichtmodell. 


Bediener 


[nern] [sommer] 


x 


Abb.1: JQMS-Architektur 


Die Grobstruktur des JQMS (Abb.1) zeigt die strikte Trennung 

der lianagement-Ebene (JQM) von der Datenverwaltung (JPS). In 

Ja: liest die Jobdurchlaufstrategie, einschließlich der Kormmu- 
nikation mit dem Bediener, also der auf den Anwendunssfall zu- 
seschnittene Teil des JQUS, während das JPS als allgemeinsülti- 
gen Komplex die Datenstrukturen, Zugriffspfade und die Speicher- 
verwaltung der Datenbasis enthält. 

Ein wichtiges lierkmal der Architektur ist die weitgehende Unab- 
höngiskeit der beiden Schichten vcneinander. So ist es ohne 
weiteres möglich, die Jobverwaltung im JQH zu verändern, ohne 
Auswirkungen auf Programme im JPS. Optimierunsen der Zugriffs- 
pfade sind umgekehrt ohne Einfluß auf die Programme möglich, die 
den Jobäurchlauf realisieren. Die Schnittstelle selbst ist ein 
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Satz leistungsfähiger Operatoren, der alle denkbaren Manipu- 
lationen mit den relevanten Elementen erlaubt. 

Die Datenwiedersewinnuns ist im JIS konzentriert. Auf der 
Grundlase des Codä'schen relationalen Datenkonzepts wird eine 
Inhaltswiedergewinnuns mit teilweiser Invertierung durchsce- 
führt 1. Das Job-File-System verwirklicht die Datenstruktur 
des Pools und verwaltet mit einer Belegungstabelle.den Spei- 
cherplatz der Datenbasis. Die physische Speicherung ist zu= 
fällig. Transferblöcke werden bei Bedarf gekettet. Im JBS 
befinden sich die Algorithmen zur Überwachung der Nutze 
budgets. 


4. Realisierung eines JQEUS 
Die Installation des JQHS an RZ der TUD zeigt Abb.2. 
ES1020 


7 
Bm & rs 


INSPECTOR | [weiter | | 


Ren ID | o— 


—- Datenfluß 
> Steverung 


Abb.2: JQMS-Installation 
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Die einzelnen Systemkomponenten haben folgende Funktionen: 
READER 


- Übernahme der primären Jobdaten von Lochkarte auf den Pool 

- Einreihen der Jobs in die entsprechende Auftragswarte- 
schlange 

- Interpretieren spezieller Jobdaten, Erzeugen von Sekun- 
därdaten zur Unterstützung der Suche 

- syntaktische Kontrolle des Jobs entsprechend der Job- 
oteuersprache BAMOS 

- Realisierung eines Packungsalgorithmus zwecks ökonomischer 
Verwenduns von Plattenspeicherplatz 

- Mivteilungen an den Bediener 


SCHZDULER 


- Bereitstellen von Jobmengen in Kommunikation mit dem Be- 
diener 

-“ flexible Haripulation der ausgewählten Menge entsprechend 
der Situation em Rechnersystem 

- Bereitstellen der endgtiltigen Jobstapel für den ;loch- 
leistungsrechner a j 


WRITER 


- Auszabe der Jobausgabeinformation 


IISPECTOR 


- Ausgabe eines Inspektionsprotokolls auf Anforderung 
durch den Bediener 

- Realisierung eines ließapparates zur automatischen 
Datensammlung 


Über diese Komponenten hinaus werden noch realisiert: 


TERNINATOR 


- Beenden einer laufenden Komponente des JQUS 
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RESTART 


- Wiederanlauf bzw. Neuanlegen eines Jobpools nach Ausnahnme- 
situationen af Trägerrechner (Maschinenfehler, Wartung o.ä.) 


5. Produktionstest 


Das JQLUS wurde schrittweise unter Produktionsbedinsungen an 
Rechnersystem BESM6/ES1020 getestet. Trägerrechner war die 
EDVA ES1020 unter Steuerung des Plattenbetriebssystenms DOS. 
Verwaltet wurden Jobs für das Betriebssystem BANOS des sowje- 
tischen Hochleistungsrechners BESM6. Abschluß, dieser Phase 
war ein einwöchiger Produktionsbetrieb, bei dem der. gesantc 
Auftragsanfall (ca. 1600 Jobs, 300 000 Lochkarten) unter 
Beibehaltung der derzeit manuell realisierten Jobdurchlauf- 
strateglien bearbeitet wurde. 

Ziel der praktischen Erprobung war es, Aussagen zu’ den 
Problenkreisen 

- Systemeigenschaften des JQUS 

= Gesamtverhalten ES1020/JQHS 

- Meßdaten Über Bedjener- und Benutzerverhalten 

zu erhalten. 


Nach den Produktionstests kann allgemein eingeschätzt werden, 
daß die Funktionsfähigkeit des JQMS nachgewiesen ist. 

Die Handhabung des Systems ist in kurzer Zeit vom Bediener 
zu erlernen. Die Robustheit gegenüber der Bedienung und be- 
züglich des Zustandes des Trägerrechners ist ausreichend. 


Als sehr flexibel erwies sich das JQUS gegenüber vorher nicht 
erkannten Anforderungen, die sich aus dem praktischen Einsatz 
unmittelbar: ergaben. Auf Grund der Systemarchitektur (Abb.1) 
war es möglich,- mit geringem Zeitaufwand die Auswahlmöglich- 
keiten im Scheduler zu erweitern bzw. den aktuellen Ver- 
hältnissen im Jobpool anzupassen und Änderungen in der Da- 
tenstruktur von einen Tas zum anderen durchzuführen. 

Die Datenreproduzierbarkeit und Datenintegrität beschränkt 
sich in der gegenwärtigen Systemversion auf die Komponente 
RESTART, Aus einer Jobrepräsentation wird eine fehlerfreie 
Struktur der Verwaltungstabellen wiederhergestellt, Die 
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Die Eigenschaften der Komponente RESTART entsprechen der An- 
forderung nach einem schnellen, sicheren und weitgehend au- 
tonatisierten Wiederanlauf. Die Sicherheit der Daten ist der- 
zeit durch die Funktionsfühigkeit äca Plattenstapels, auf dem 
sich die Datenbasis befindet, begrenzt, 

Boi der Betrachtung des Gesamtsystens Trägerrechner/JQUS sind 
die Aspekte Leistungsfähigkeit und Zuverlässigkeit interessant. 
In unserem Falle kann die Leistungsfähigkeit, bezogen auf den 
Datenanfall, als ausreichend bowertet werden. So beträgt z.B. 
die reale Leistung für die Lochkarteneingabe ca. 5 IK/sec. 
Die maximale stündliche Ankunftsrate wurde mit 10 563 IK ge- 
‚messen. Das würde einer Auslastung von etwa 60% entsprechen. 
Im Gesämtdurchschnitt erzibt sich eine IKE-Auslastung von ca. 
40%. Ähnliche Verhältnisse sind für die Druckerausgabe abzu- 
schätzen. 

Wesentlich kritischer ist die Zuverlässigkeitsanforderung zu 
betrachten, Her geht neben der sporadischen Ankunftsrate die 
Jobdurchlaufstrategie ein. Da wir letzlich eine durchgehende 
Prioritätest. .ategie realisieren wollen, ist die Eingabe der 
Jobs unmittelbar bei Abgabe erforderlich. Damit verlangen wir 
die ständigo Verfügbarkeit der READER-Punktion während der ge- 
santen Öffnungszeit der Jobannahlme. Darüberhinaus vorlangen 
garantierte Antwortzeiten entsprechend: der Priorität einer 
Aufgabe dio Verfügbarkeit des Trägerrochners für die Kompo-= 
nenten SCHEDULER und WRITER. Die einzelnen Komponenten arbei- 
sen dabei im Multiprogramming. Da wir in diesen Zeitraun, 
während der Öffnungszeit der Jobannahne, eine unmittelbare 
Prozeßsteuerung durchführen wollen, sind die Sicherheitsan- 
forderungen auch entsprechend hoch. In den übrigen Zeiten, 
insbesondere auch an den Wochenenden, werden die Anforderun- 
gen vornehmlich durch den Jobdurchlauf bestimmt und es erge- 
ben sich srößore, zusammenhängende Zeiträume, in. denen die 
Nichtverfügbarkeit des Gesantsystems ohne spürbare Auswirkun- 
gen auf den technologischen Ablauf bleibt. Die uns zur Ver 
fügung stehende. technische Basis des ES 1020 konnte den 
skizzierten Anforderungen nicht genligen. 

Die zum Bediener bzw. Rutzerverhelten mttterten Daten 
bedürfen - auf Grund der relativ geringen Testmöglichkeiten - 
zu ihrer Bestätigung weiterer Nessungen. 
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Simulationsmodell der Stspelverarbeitung im Multiprogrammbetrieb 


Doz. Dr. sc. techn. Gerhard Bergholz 
Gabriele Mrosko 


1. Optimierung durch Variantenvergleich und Nutzensnachweis mit 
Hilfe der Simulation 


In den kommerziellen Rechenzentren werden Projekte der Massen- 
dJatenverarbeitung, für die verschiedenen Abarbeitungsvarianten 
(täglich, wöchentlich, monatlich) exiötieren können, periodisch 
abgearbeitet. 

Ein Projekt umfaßt ca. 50-200 Jobs, die durch die Erzeugung und 
den Verbrauch vor. Dateien voneinander abhängig sind. 

Die Jobs eines Projektes bilden ein Jobnetz, dessen Aberbeitung 
durch das erweiterte Programmsystem IEFBR14 automatisch gesteuert 
wird. 

Durch die geeig..ete Gestaltung der Jobnetze bzw. durch die ver- 
schachtelte A’ arbeitung mehrerer Jobnetze ist eine Maximierung 

der Parallelität mit dem Ziel der Leistungserhöhung möglich, 

Dabei ist zunächst die Aufstellung eines maximal parallelen 
Jobnetzes unter Berücksichtigung der logischen Abhängigkeiten 

der Jobs erforderlich. 

Anschließend erfolgt die Anpassung des maximal parallelen Jobnetzes 
an die entsprechend der Konfiguretion vorhandenen Ressourcen 
(Partitionenzahl, verfügbare periphere Geräte). 

Zur Lösung dieser Aufgaben werden die Methoden der Netzplantechnik 
nit beschränkten Ressourcen herangezogen. 

Es hat sich gezeigt, daß die Parallelität ein Maximum annimnt, 
wenn die Jobs mit der größten Jobverweilzeit den Vorrang erhal- 
ten /2/. 

Bei bekannten Jobverweilzeiten kann durch Ermittlung der Dauer 

des kritischen Weges die Projektlaufzeit vorhergesagt werden. 
Dabei bleibt die Laufzeitverlängerung der Jobs, die durch die 
Erhöhung der Parallelität zustande kommt, unberücksichtigt. 

Un exakte Aussagen Über die voraussichtliche Projektlaufzeit 
treffen zu können, sind weiterführende Untersuchungen erforderlich. 
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Diese können mit Hilfe 
- einer Projektunstellung und anschließender Systemmessung 
- der Nutzung bedienungs- und wahrscheinlichkeitstheoretischer 

kodelle oder 
- der Simulation 
durchgeführt werden. 
Die erste Möglichkeit ist.sehr zeit- und kostenaufwendig und die 
Ergebnisse sind sclwer reproduzierbar. 
Die handhabbaren bedienungstheoretischen Modelle setzen ein kon- 
stantes Jobprofil (das in unserem Fall nicht gegeben ist) voraus. 
Es ist nicht möglich, Prioritäten, die auf die Zuteilung der Zen- 
traleinheit Einfluß haben, zu berücksichtigen. 
Als Ausweg bieten sich die Simulationsuntersuchungen an. 
Neben der voraussichtlichen Leistungserhöhung durch Maximierung 
der Parallelität können Möglichkeiten der Leistungssteigerung 
durch verschiedene Auswahlstrategien der ZVE (Zeitscheibentechnik, 
absolute Prioritäten) überprüft werden. 


2. Aufbau des Simuletionsmodells 


Auf der Basia des PS SIMDIS wurde ein Sinulationsprogramm ent- 
wickelt, das die Stapelverarbeitung unter Steuerung des Betriebs- 
systens OS/ES MFT nachbildet. 


2.1. Eingangsgrößen für das Simulationsprogramnm 


Dem Programm sind folgende Eingengsgrößen zur Verfügung zu stellen: 


- Partitionaufteilung (Partitionnr., zugeordnete. Job- 
klassen) 

- Konfiguration (Zahl der verfügbaren Geräte je 
Geräteklasse) 

= Struktur’ des Jobstapels (Abhängigkeitsmatrix) 

Für den nachzubildenden Job werden folgende Daten gefordert: 

- Jobklasse (entsprechend CLASS-Parameter) 

- Startpriorität (entsprechend PRTY-Paraneter) 

- Bedarf an fest zugeord- (Zahl der Ressourcen einer Ge- 

neten Ressourcen räteklasse, die dem Job während 

der gesamten Laufzeit zugewie- 
sen sind) 

= mittlere Bedienungszeit (Zeit für die Verarbeitung eines 


je Zugriff \ physischen Satzes) 
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- Zugriffchäufigkeiten zu den 
peripheren Geräten. 


2.2. Beschreibung des Simulationsmodells 


Zur Darstellung des simulierten Modells bietet sich die Forderungs- 
laufplantechnik nach Bergholz /1/ an. Der Forderungslaufplan kann 
mit geringem Aufwand in einen SIMDIS-Aktivatorlaufplan umgesetzt 
werden. j 

In der Abbildung 1 ist der Forderungslaufplan (FLP) für die Abar- 
beitung eines einfachen Jobnetzes gegeben. 

Die grafische Darstellung ist folgendermaßen zu interpretieren: 

Die Forderungsquelle erzeugt für jeden nachzubildenden Job einen 
Aktivator. 

Alle abhängigen Jobs verbleiben bis zur Freigabe nach der ordnungs- 
gemiißen Beendigung ihrer Vorgänger in der HOLD-Kette (Job 2 - Job. 4). 
Die unabhängigen Jobs (Job 1.) reihen sich in die ihren CLASS-Para- 
meter entsprechende Jobwarteschlange ein und warten auf die Zuwei- 
sung eines geeigneten Hauptspeicherbereiches, 

Für die Jobs (iner Klasse erfolgt die Vergabe der Partitions ent- 
sprechend dem PRTY-Parameter. 

Bei Freiwerden eines Hauptspeicherbereiches wird für den ausge- 
wählten Job überprüft, db alle benötigten Ressourcen verfügbar 
sind. Ist das nicht der Fall, wird dieser Job suspendiert und ein 
anderer zur Verarbeitung freigegeben. 

In der Abbildung 2 ist der FLP für die Abarbeitung eines Jobs im 
Kultiprogrammbetrieb gegeben. 

Nach der Zuweisung aller fest zugeordneten Ressourcen stellt der 
Jot abwechselnd Bedienungsanforderungen an die Informationsaus- 
tauschrersourcen (IAR) und die 2VE, 

Rei den IAR sind die geteilt genutzten IAR und die dem Job fest 
zugscrdneten Ressourcer zu unterscheiden. 

Zu den geteilt genutzten IAR zählen reten den Systemdateien alle 
Dateien des lodus SER, ‚die Selektorkanäle und die zugehörigen pro- 
grammtechnischen Ressourcen. 

Zu den fest zugeordneter Ressourcer gehören alle peripheren Geräte, 
Gie Üter den Multiplexkenal engesprochen werden. Die Wartezeiten, 
die vor diesen Ressourcen entstehen, können. vernachlässigt werden, 
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Die. Wahrscheinlichkeit. für den Zugriff zu einer IAR kann man durch 
die relative Zugriffshäufigkeit annähern. 

In den IAR werden die Jobs entsprechend der Reihenfolge ihrer An- 
kunft (FIFO) bedient. 

Nach jedem Informationsaustausch folgt ein Verarbeitungsschritt. 
In dem Simulationsmodell werden die beiden Möglichkeiten, die im 
OS/ES für die Vergabe der ZVE existieren, berücksichtigt. Durch 
Eingabe eines Parameters kann man steuern, welche der Varianten ab- 
zuarbeiten ist. 

Die absoluten Prioritäten für die Vergabe der ZVE sind analog den 
OS/ES den Programmbereichen fest zugeordnet. 

Bei der Nutzung der Zeitscheibentechnik ist die Größe der Zeit- 
scheibe variabel und dem Programm zur Verfügung zu stellen. 

Alle Bedienungszeiten einer Forderung werden als exponentiell ver- 
teilt angenommen, 

Der Wechsel von Informationsaustausch und Verarbeitung wird pro 
Job sooft durchlaufen, wie physische Datensätze zu verarbeiten 
sind. 

Aus der Abbildung 2 ist ersichtlich, daß die Abarbeitung eines Jobs 
sequentiell erfolgt. 

Nach Beendigung eines Jobs werden alle ihm fest zugeordneten Reg- 
sourcen freigegeben. Die Nachfolgerjobs können die HOLD-Kette ver- 
lassen und sich in die Jobwarteschlange einreihen. 

Alle Bedienungszeiten der Aktivatoren und die Verweilzeit werden 
erfaßt. Die Meßstellen sind aus den Abbildungen 1 und 2 ersicht- 
lich. 
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2.3. Ergebrisse der Simulation 


Arm, 
Als Ergebnisse der Simulation Huden-zur jeden Jobs folgende 
Größen ausgegeben. ; 
- Jobnr. 
- Partitionnr. 
- Startzeit 
- Stopzeit 
- Bedienungszeit 
- Verweilzeit 


- Verweiizcitfaktor (Maß für Laufzeitverlängerung ei- 
" res Jobs im Multiprogrammbetrieb 
gezenüber dem Solobetrieb) 


- dwrchschnittliche Anzatkl 

der Unterbrechungen für 

eine ZVE-Bedienungs 
Der letztgenanrite Wert ist von Interesse, um einen Vergleich zwi- 
schen der Verg.te der Z2VE nach absoluten Prioritäten bzw. nach 
Zeitscheibentec.nik durchzuführen und die optimale Auswahlstrategie 
für eine Proj .ktabarbeitung festzulegen. 
Für jeden nachzubildenden Jobstapel werden neben der Start- und 
Stopzeit der Verweilzeitfaktor, der Leistungsfaktor (als Maß für 
die bewältigte Bedienungszeit im Beobachtungszeitraum), die Aus- 
lastung aller Ressourcen und die Beschäftigungskoeffizienten aller 
Ressourcen ausgedruckt. 


Nachweis der .Adäquatteit des Sinulationsmodells 


Ss ist zu Überprüfen, inwieweit bei gleichen unabhängigen Einfluß- 
faktoren die durch die Messung realen System gewonnenen Bewer- 
tungsgrüßen mit den durch die Anwendung ces Modells gewonnenen Be- 
wertungsgrößen übereinstimmen. 

Die Grurdlage für den Adäqustheitsnachweis bildet ein Benchmark- 
Test, der durch die GTF-Routiner erfaßt wurde. 

Zu dem Vergleich wurden folgende Dewertungssräßer herangezogen: 

- die Auslaätungsgrade zller Ressourcen 

- ger Leistungsfaktor während der Abarbeitung des Stapels, 

Ein Systerjob tildst die durch den ÜOverliead erzeuzte Arbeitslast! 
nach. Für diesen Job wird während der Simulation eine Inaktivitäts- 
phase eingeführt, um zu garantieren, daß während des gesanten Beob- 
achtungszeitraumes das System aktiviert werden kann. 
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In der Tabelle 1 ist eine Gegenüberstellung der. Ergebrisse des 
Simulationsversuches mit, denen des Benchmark=-Tests enthalten. Die 
maximale Abweichung der Bewertungsgrößen beträgt rund 7 %. Dieses 
Resultat berechtigt zu der Annatime, daß das Simulationsmodell zur 
Nechbildung der Stapelverarbeitung im Multiprogranmmbetrieb ge- 
nutzt werden kann. 


4s Beispiele für die. Anwendung des Simulationsmodells 
> 


Yit Hilfe der Simulation wurden mehrere Projekte des DVZ Dresden, 
während deren Abarbeitung die Auslastung der Ressourcen relatlv 
gering ist, auf die Möglichkeit einer Leistungssteigerung durch 
Erhöhung der Parallelität innerhalb des Projektes oder durch pa- 
rallele Verarbeitung mit einem anderen Projekt, überprüft. Der 
Vergleich der mittels Simulation nachvollzogenen realen Abarbei- 
tung mit der optimierten Abarbeitung ergab für die Erhöhung der 
Parallelität innerhalb eines Projektes die in der Tabelle 2a: zu- 
sammengestellten Bewertungsgrößen. 

Die Tabelle 2b zeigt die Bewertungsgrößen für die parallelisierte 
Abarbeitung zweier Projekte, die bisher nacheinander abgearbeitet 
wurden. 

Ein Vergleich der Leistungsfaktoren zeigt, daß die größten Reser- 
ven für eine Leistungserhöhung bei der Parallelisierung der Abar- 
beitung mehrerer Projekte liegen. 
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Tabelle 1: Gegenüberstellung der Bewertungsgrößen während des 
Benckmark-Tests mit den Simulaetionsergebnissen 


x 


Simulation Benchnark-Test 
[544 
’ ’ 


2. — Auslastungsgrad IAR O 
y. 7 Auslastungsgrad IAR 1 
7, — Aus lastungsgrad IAR 2 
Pays” Auslastungsgrad ZVE 
R - leistungsfaktor 


Tabelle 2a: Durch Erhöhung der Parallelität innerhalb eines Pro- 
jekces erreichbare Verbesserungen 


Projekt 1] reale Abarbeitung 21388 
optim. Abarbeitung | 2071s 


Projekt 2| reale Abarbeitung |10 4025 
optim. Abarbeitung | 8 0075 


Tabelle 2b: Durch die parallele Verarbeitung mehrerer Projekte 
erreichbare Verbesserungen \ 


T, - Beschäftigungszeit für die‘ Abarbeitung eines Jobstapels 
E - Multiprogrammfaktor 
F - Verweilzeitfaktor 

R - Leistungsfaktor 


—_ 
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Abbildung 1: FLP für die Abarbeitung eines einfachen Jobnetzes 
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Ahbildung 2: FLP für die Abarbeitung eines Jobs im Multiprogramn- 
betrieb 
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